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Research  Objective 


The  objective  of  this  project  Is  to  determine  the  technical 
feasibility  of  replacing  COBOL  with  Ada  within  the  Department  of 
Defense  (DoD),  and  thus  establishing  Ada  as  the  standard  programming 
language  for  management  Information  systems  (MIS).  Motivation  for 
this  study  is  the  growing  support  of  Ada,  both  In  government  and 
the  private  sector,  for  a  wide  variety  of  applications,  not  just  the 
originally  intended  embedded  computer  software.  There  is  a  need 
to  rationally  evaluate  Ada  for  MIS.  This  will  provide  some  basis  for 
MIS  developers  to  welcome  or  reject  future  proposals  to  extend  the 
scope  of  the  DoD  Ada  standardization  decrees. 

Rationale  for  Ada 

Let  us  go  down,  and  there  confound  their  language, 
that  they  may  not  understand  one  another's  speech. 

(the  book  of  Genesis) 

The  Army,  Navy  and  Air  Force  have  independently  developed  or  used  an 

assortment  of  programming  languages,  many  of  which  are  used  by  only 

one  service  CGLAS79J.  This  proliferation  hinders  sharing  of  products 

and  services.  Also  a  problem  Is  the  widespread  use  of  assembler 

language  P1ART79J.  Assembler  code  Is  difficult  (and  therefore  costly) 
to  understand,  debug  or  modify.  The  difficulty  to  change  assembler 
software  Is  slgnlflc?  t  because  military  requirements  and  environments 
are  particularly  suuject  to  change,  and  necessary  alterations  to 


software  can  consume  more  resources  than  did  the  original  development. 
Assembler  code  Is  difficult  to  test,  since  algorithms  are  usually 
obscured  in  a  maze  of  microscopic  detail.  Therefore  the  testing 
process  Is  costly,  and  critical  errors  may  survive  and  plague  the 
delivered  system.  Since  assembler  languages  are  usually  unique  for 
each  different  machine,  software  Is  not  portable.  It  Is  restricted  In 
application.  Thus  use  of  assembler  contributes  to  software 
proliferation,  and  the  military  Is  vulnerable  to  support  problems 
which  could  occur  If  the  sole  source  of  a  machine  goes  out  of  business 
or  discontinues  a  product  line.  The  manufacturer  may  be  the  only 
source  of  assembler  language  support. 

About  half  of  Department  of  Defense  software  costs  are  attributed 
to  embedded  computers,  that  Is,  computers  which  are  themselves  com¬ 
ponents  of  a  weapons  system  |8UXT8Q).  This  software  often  has 
distinctive  characteristics:  the  ability  to  continue  to  operate  after 
hardware  or  software  faults,  connection  with  unusual  peripheral  equip¬ 
ment,  monitoring  of  sensors,  control  of  special  displays,  and  the  need 
to  respond  to  real  time  events  {8UXT80] .  Assembler  seems  appropriate 
In  many  applications  where  needed  features  do  not  exist  In  high  order 
languages  (HOI),  and  therefore  compiler  generated  code  Is  Inefficient. 

In  recent  years  hardware  costs  have  been  decreasing  as  software 
costs  have  risen,  and  the  run  time  Inefficiencies  of  HOL  have  become 
more  tolerable.  Particularly  attractive  to  Department  of  Defense  Is 
the  potential  Increase  In  programmer  productivity.  Assuming  It  takes 
about  the  same  effort  to  produce  one  line  of  assembler  code  as  one 
line  of  HOL  code,  and  If  one  line  of  HOL  code  produces  10  lines  of 


assembler  code,  great  savings  are  possible  during  development  and  dur¬ 
ing  Implementation  of  system  changes  CHART79J . 

Department  of  Defense  has  taken  a  number  of  strong  measures  to 
combat  software  proliferation.  Realizing  the  Increasing  benefits  of 
HOL  programming,  to  achieve  a  short  term  Impact  they  Issued  Directive 
5000.29,  which  required  use  of  HOL  unless  it  could  be  "demonstrated 
that  none  of  the  approved  high  order  languages  are  cost  effective  or 
technically  practical  over  the  system  life  cycle"  £GLAS79J.  Shortly 
afterward.  Directive  5000.31  specified  seven  existing  high  order 
languages  as  the  only  ones  permitted  for  Department  of  Defense 
systems:  FORTRAN  and  COBOL  (widely  used);  TACPOL  (Army);  CMS-2  and 
SSPL  (Navy);  JOVIAL,  J3  and  J-73  (Air  Force)  EMART79J.  In  1975  a  High 
Order  Language  Working  Group  (HOLWG)  was  commissioned  to  develop  a 
common  HOL  for  Department  of  Defense  JWHIT79J. 

The  HOLWG  was  not  christened  impulsively.  A  1977  study  by  MITRE 
Corporation,  based  on  extremely  conservative  assumptions,  estimated 
that  a  common  language  would  save  $110  million  to  $900  million  during 
1983  -  1999  |MART79].  Studies  by  the  Defense  Advanced  Research 
Projects  Agency  and  by  Decisions  and  Designs,  Inc.,  based  on  more 
realistic  assumptions,  predicted  savings  of  $12  to  $24  billion 
JMAR79J.  The  Initial  HOLWG  objective  was  to  determine  requirements 
for  a  common  language.  A  series  of  draft  requirements  documents  were 
developed  and  circulated  among  military  departments,  government 
agencies,  Industry  and  academic  Institutions.  As  reactions  to  each 
draft  were  evaluated,  the  product  became  more  solid.  The  names  of  the 
papers  reflect  this  solidarity:  STRAWMAN  (1975),  WOODENMAN,  TINMAN, 
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IRONMAN  ,  STEELMAN  (1978)  |GLAS79J.  The  proposed  new  language  was 
named  Ada,  after  Ada  Augusta  —  the  world's  first  programmer  [ICHB79], 

She  worked  for  Charles  Babbage  during  his  development  of  the 
Difference  Engine  and  Analytical  Engine  circa  1829  [GLAS79J. 

After  evaluating  existing  languages,  the  HOLWG  found  none 
adequate  to  handle  the  requirements,  but  three  were  selected  as  can-  4 

didate  base  languages:  Pascal,  PL/1  and  ALGOL  68.  They  did  conclude 
that  It  would  be  practical  and  entirely  satisfactory  to  develop  a 
derivative  of  an  existing  language  rather  than  an  entirely  new  one. 

In  1977  four  contractors  were  selected  to  design  the  Ada  language 
using  any  one  of  the  base  languages.  All  chose  Pascal.  In  April 
1979,  the  design  of  C11  -  Honeywell  Bull  was  declared  the  winner 
[GLAS79J .  The  Department  of  Defense  has  since  sponsored  Ada  training 
sessions  for  Interested  Industry  representatives,  and  the  HOLWG  has 
considered  their  feedback  In  further  refining  Ada. 

Certain  to  add  momentum  to  the  Ada  program  Is  the  Army's  award  of 
a  contract  In  1980  for  development  of  an  Ada  compiler  for  the  VAX 
11/780.  The  compiler  should  be  completed  In  1982,  tested  and 
certified  by  1983  [LEI80B] .  The  HOLWG  plans  development  of  an  Ada 
Programming  Support  Environment,  a  set  of  Integrated  software  tools 
for  Ada  software  development.  When  completed,  the  Army  will  Install 
this  environment  on  a  VAX  to  establish  a  software  development  facility  * 

[11].  The  target  date  for  the  complete  facility  Is  1983  [LEI80BJ. 

% 

Certain  Ada  features  are  directly  related  to  the  typical  military 
requirements  described  earlier: 

-  Facility  for  parallel  tasks  (Initiation,  termination,  rendez¬ 
vous)  for  real  time  systems  [ICH79B]. 
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-  Exception  handling,  for  establishing  capability  to  survive  har¬ 
dware  or  software  errors  JICH79BJ. 

Other  features  facilitate  system  development  and  portability  IICHB79J: 

-  Separately  compilable  program  units. 

-  User  defined  abstractions  whose  implementation  details  may 
be  "hidden". 

Military  Computer  Family 

Ada  is  oriented  towards  embedded  computers.  Yet  DoD  may  in  the 
future  pursue  even  greater  standardization  by  establishing  Ada  as  the 
common  HOL  for  all  applications,  including  MIS.  A  related  Army 
project.  Military  Computer  Family  (MCF)  may  give  added  impetus  to  this 
idea.  The  MCF  proposes  to  attack  hardware  proliferation  by  fielding 
an  instruction-set-compatible  family  of  battlefield  computers, 
designed  to  be  efficient  target  machines  for  Ada  compilers.  An  in 
depth  study  of  future  Army  requirements  shows  conclusively  that  two 
computer  models,  a  micro  and  a  mini,  will  satisfy  virtually  all  batt¬ 
lefield  applications  in  the  1980's  [C0MP80J.  Accepting  the  study 

results,  the  MCF  project  proposes  development  of  a  micro  and  a  "super 
mini"  model  using  1984  technology  for  1986  delivery  [LEI80BJ.  Hard¬ 
ware  specifications  are  based  on  forecasts  of  the  1984  state  of  the 
art  In  order  to  postpone  the  techno’o:/  lock-in  as  long  as  possible. 

The  microcomputer,  dubbed  the  AN/UYK-41V1,  is  to  satisfy  the  fol¬ 
lowing  constraints: 

-  Size:  Contained  on  a  6"  by  9"  card  (not  including  power  sup¬ 

ply)- 


;  t 
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-  Weight:  Less  than  12  ounces. 

-  Speed:  500,000  Instructions  per  second. 

-  Store:  128K  bytes. 

-  Cost:  $5,000  In  1980  dollars. 

-  Reliability:  100,000  hours  mean  time  between  failures. 

-  Power:  Less  than  5  watts. 

Though  not  required.  It  Is  quite  possible  that  this  micro  might  be 
able  to  perform  as  a  component  of  its  big  brother,  the  "super-mini" 
AN/UYK-41V2. 

The  V2  specifications  are  listed  below: 

-  Size:  Contained  In  an  air  transport  rack,  7"  tall,  10"  wide 
and  13.5"  deep  (.5  cubic  feet). 

-  Speed:  3 ,000,000  Instructions  per  second. 

-  Store:  2  Megabytes. 

-  Cost:  $75,000  In  1980  dollars. 

-  Reliability:  10,000  hours  mean  time  between  failures. 

-  Power:  100  watts. 

The  size  of  the  VI  and  V2  computers  allows  a  wide  range  of 
application  among  battlefield  systems.  The  larger  V2  is  about  the 
same  size  as  the  ubiquitous  Army  FM  radio  (VRC-12,  VRC-46)  commonly 
Installed  In  jeeps,  armored  personnel  carriers  and  tanks.  The  VI  Is 
even  smaller  than  the  standard  Army  manpack  radio  (PRC-77). 

The  Army  will  select  up  to  four  contractors  to  completely  design 
the  MCF  models  by  1983.  Recall  that  the  Inner  workings  of  the  com¬ 
puter  box  are  largely  at  the  discretion  of  the  manufacturer,  so  each 


contractor  may  develop  an  independent  design.  Producers  of  the  two 
best  designs  will  be  given  the  go-ahead  to  develop  prototypes  by  1985. 
After  extensive  testing,  the  winner  will  be  selected  for  full  scale 
production  beginning  in  1985.  First  production  models  should  appear 
in  1986. 

In  order  to  transition  smoothly  to  the  MCF,  the  Army  will  develop 
a  "software  MCF"  by  1983:  an  Ada  compiler,  MCF  simulator  and  tactical 
operating  system  on  a  commercial  host  computer.  Therefore  software 
targeted  for  MCF  models  can  be  developed  and  tested  as  the  computers 
are  being  built  [LEIB80].  Further  Information  on  the  MCF  project  and 
architecture  of  the  MCF  machines  is  contained  in  an  earlier  report 
£DAVI80]. 

Implications  of  Ada/MCF  for  MIS 

The  characteristics  of  the  MCF  computers  make  them  front  runner 
candidates  for  battlefield  and  other  management  information  system 
hardware.  For  example  the  MCF  mini  will  be  smaller  and  more  powerful 
than  the  van  mounted  DAS3  minicomputer  being  fielded  in  1980  to  sup¬ 
port  logistical  MIS  for  maintenance  units.  MCF  computers  are  logical 
replacements  for  the  DAS3  and  for  the  aging  IBM  360/30  machines  serv¬ 
ing  Army  divisions.  Many  Army  activities  are  formulating  plans  for 
Increased  automation  of  the  battlefield,  including  new  applications  of 
MIS  using  portable  or  mobile  computers. 

A  recent  Arm;  policy  memorandum  requires  that  all  future 
automated  battlefield  systems  use  MCF  hardware  and  Ada  software 
JARMY80J.  At  this  time  it  is  not  clear  whether  the  policy  applies  to 


management  information  systems  which  operate  in  whole  or  in  part  in 
the  battlefield  environment.  I  see  the  handwriting  on  the  wall.  I 
expect  Ada  to  be  used  for  future  battlefield  MIS. 

Since  embedded  computers  (and  hence  MCF)  will  be  purchased  in 
record  numbers  during  the  next  ten  years,  the  inevitably  rich,  Ada- 
oriented  base  of  software  development  tools  and  application  programs 
will  increase  the  attractiveness  of  using  Ada  for  MIS.  Future  tac¬ 
tical  MIS  will  interface  with  other  major  components  of  a  battlefield 
automated  system.  A  common  language  and  support  environment  will 
contribute  to  an  Integrated  logistics  concept  with  the  potential  for 
considerable  cost  reduction. 

What  is  a  Management  Information  System? 

Management  information  Systems  (MIS)  are  designed  to  "aid 
management  in  organizational  planning,  operation  and  development" 
[ENCY76J.  There  appears  to  be  no  widely  accepted  definition  beyond 
this  general  description. 

Managers  are,  the  name  MIS  implies,  an  important  class  of  users 
of  the  system.  The  Information  system  helps  them  plan,  make  decisions 
and  control  their  organization.  Features  often  found  in  MIS  are 
[ENCY76J : 

-  a  database  representing  the  organization  and  its  environment 

-  simulation  capability,  based  on  the  database  or  a  "corporate 
model"  derived  from  it 

-  decision  support  tools 

-  Information  summaries  and  analyses 

-  an  Information  retrieval  system. 

The  term  MIS  in  this  paper  refers  to  the  broadest  possible 
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context;  emphasis  is  on  "Information  system"  rather  than  on 
"management."  I  believe  this  describes  a  meaningful  class  of  systems 
which  have  evolved  from  the  original  "ADP"  systems. 

When  computers  were  first  introduced,  organizations  employed  them 
as  labor  saving  devices.  Clerical  functions  were  automated  to  reduce 
administrative  labor  and  cost.  Routine,  recurring  functions  were  the 
principal  targets  for  automation  (inventory,  payroll,  etc.).  Usually 
the  automated  system  was  a  mirror  image  of  the  corresponding  manual 
system.  Data  was  stored  in  master  files,  usually  magnetic  tape,  and 
processing  consisted  of  having  transactions  update  the  master  files. 

Many  MIS  currently  in  use  resemble  the  old  fashioned  ADP  systems: 
they  are  based  on  sequential  files  and  periodic  processes  which 
operate  on  them.  Summary  reports  do  help  managers  make  decisions,  but 
such  MIS  support  the  activities  of  personnel  throughout  the 
organization.  A  stock  control  system  may  interface  with  salesmen, 
stock  clerks,  finance  clerks  and  others  —  it  is  not  necessarily  just 
a  management  tool. 

The  trend  in  modern  MIS,  made  possible  by  more  prevalent  random 
access  devices,  is  toward  integrated  database  management  systems. 
This  trend  reflects  the  need  to  correlate  information  on  all  aspects 
of  an  organization.  Formerly  data  was  fragmented  among  the  master 
files  of  the  various  MIS.  It  could  not  conveniently  be  accessed  or 
processed  other  than  through  the  indiv'jual  MIS.  Also  reflected  in 
this  trend  is  the  requirement  to  respond  to  changes  in  managers' 
needs.  The  summary  reports  of  the  old  style  MIS  are  frozen  in  content 
and  format.  Revising  Lhem  requires  a  time  consuming  and  expensive 
reprogrammi ng  effort. 
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Perhaps  MIS,  as  used  here,  can  be  most  concisely  defined  as 
"systems  which  aid  management  and  others  in  organizational  planning 
and  operation." 

Characteristics  of  MIS  include: 

-  large  volume  of  data  (input,  master  files  and  output) 

-  relatively  simple  transactions  on  the  data 

-  many  routine  manual  processes  are  emulated  or  supported 

-  large,  complex  systems  having  numerous  processes  and  interfaces 
with  many  different  users  or  other  MIS. 

The  COBOL  Realm 

In  this  report  COBOL  refers  to  the  language  defined  in  "American 
National  Standard  Programming  Language  COBOL,"  ANSI  X3.23  0  1974 
IANS I 741 .  Though  a  new  version  may  be  released  in  1980,  the  analysis 
in  this  paper  remains  valid.  Initially  defined  in  1959,  COBOL  is  a 
full  twenty  years  older  than  Ada. 

COBOL  Is  designed  to  facilitate  handling  large  volumes  of  data, 
such  that  input/output  is  one  of  the  most  Important  aspects  of  a 
typical  program.  Use  of  large  files  on  external  mass  storage  devices 
Is  endemic.  This  is  "business  data  processing,"  an  application  realm 
where  perhaps  the  most  characteristic  function  is  to  process  a 
sequence  of  records,  performing  rudimentary  computations  on  each  and 
putting  the  results  Into  another  set  of  records.  Management  Informa¬ 
tion  Systems  (MIS)  have  this  same  flavor,  sometimes  with  the  addition 
of  statistical  or  decision  making  packages. 
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COBOL's  age  and  popularity  give  it  an  enormous  headstart  over  the 
newcomer  Ada.  There  are  more  programs  written  in  COBOL  than  any  other 
language  [SHAW78J. 

Application  Environment 

The  COBOL  application  environment  chosen  for  this  analysis  is 
that  of  the  U.S.  Army  Computer  Systems  Command,  which  develops  stan¬ 
dard  Army  management  information  systems  for  Army  units  and  instal¬ 
lations  worldwide.  Systems  developed  include  personnel,  logistics  and 
financial  management  systems  bearing  strong  resemblance  to  their 
counterparts  in  the  business  community.  Thus,  there  is  some 
justification  in  the  assumption  that  a  representative  environment 
exists  for  COBOL  programming  in  general. 

Decision  Factors 

The  decision  whether  to  adopt  a  new  standard  language  for  a  class 
of  applications  is  impacted  by  many  considerations,  which  I  group  into 
two  categories: 

-  "steady  state"  factors  (how  suitable  is  the  language  for  coding 
new  programs?) 

-  transition  factors  (how  costly  is  the  conversion  to  a  new 
language?) 

The  latter  category  Includes  retraining  of  programmers  and  con¬ 
version  of  existing  software,  unless  It  Is  to  be  maintained  in  the 
original  language  for  ihe  duration  of  the  life  cycle.  I  suspect  that 
though  they  are  significant  and  may  be  paramount,  transition  costs  are 


similar  for  adoption  of  any  new  language.  Retraining  of  programmers 
will  of  course  be  less  if  the  new  language  does  not  require  a  major 
reorientation  of  the  programmer's  approach. 

Since  the  transition  is  the  first  Issue  to  be  conquered,  the  Com¬ 
puter  Systems  Command  commander  is  justifiably  concerned  about  the 
difficulty  of  a  conversion  to  Ada.  An  analysis  of  this  problem 
including  alternative  approaches,  estimation  of  dollar  costs  and 
estimation  of  Impact  on  service  to  the  user  community,  is  essential  to 
the  making  of  an  intelligent  decision  on  the  adoption  of  a  new 
language.  Yet  In  the  long  run,  steady  state  costs  (or  savings)  will 
overshadow  start-up  costs. 

I  concentrate  here  on  examining  the  steady  state,  technical 
Issues,  and  defer  until  later  a  study  of  the  transition  problem.  I  do 
take  somewhat  of  a  transition  oriented  approach  in  that  I  attempt  to 
view  Ada  through  the  eyes  of  a  "COBOL-minded"  programmer.  Nlklaus 
Wirth  £WIRT74]  might  object  to  this  approach,  since  it  seems  to  be 
concerned  with  giving  the  COBOL  programmer  what  he  thinks  he  wants 
rather  than  what  he  needs.  Wirth  would  support  Ada  for  MIS  if  it 
proved  to  be  a  language  with  a  sound  (though  Initially  foreign)  set  of 
tools  for  solving  the  problems  confronting  today's  COBOL  programmer. 

Research  Approach 

I  select  what  I  believe  to  be  some  of  the  key  features  of  COBOL 
and  compare  what  Ada  has  to  offer  on  a  feature  by  feature  basis.  In 
the  discussion  of  each  feature  I  explain  why  the  feature  Is  or  Is  not 
Important.  The  Ada  solutions  to  COBOL  features  are  in  many  cases  an 
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emulation  of  COBOL  constructs.  Intended  to  be  rather  easy  for  a  newly 
converted  COBOL  programmer  to  grasp.  There  Is  no  requirement  for  a 
new  language  to  provide  parallel  capabilities  or  to  mimic  constructs 
of  the  language  it  is  to  replace.  Probably  most  COBOL  programmers, 
after  mastering  Ada,  would  employ  a  new  programming  style  in  the 
spirit  of  the  new  language.  Criticism  may  be  levelled  at  the  Idea  of 
considering  COBOL  at  all;  perhaps  the  characteristics  of  business  data 
processing  should  be  the  prime  crlterea,  not  the  COBOL  language.  I 
proceed  without  resolving  that  question,  but  make  the  assumption  that 
there  Is  some  merit  in  comparing  against  the  time  proven  standard 
bearer. 

A  word  of  caution  is  In  order:  the  Ada  code  in  the  examples  has 
not  been  checked  by  a  compiler,  since  there  was  none  available  at 
press  time.  There  is  no  claim  to  correctness.  The  examples  merely 
represent  my  best  effort  at  interpreting  the  Ada  reference  manual  [ADA 
80] . 

Design  Goals 

In  the  introduction  of  the  Ada  manual  [Ada  80],  design  goals  are 
grouped  in  three  categories: 

Reliability 

Programing  as  a  human  activity 

Efficiency. 

The  following  subgoal-,  are  spawned  by  program  reliability: 

Readability 

English-1  Ike  constructs 


-13- 


Avoidance  of  error-prone  notation 

Separate  compilation  of  program  units. 

The  COBOL  1974  standard  CANS 1743  does  not  include  design  goals, 
and  I  therefore  assume  that  the  1968  goals  are  still  valid.  The  first 
two  Ada  reliability  subgoals  coincide  with  well  known  advantages  of 
COBOL  [KREK79J.  Readable,  English- like  notation  has  remained  a 
principal  design  goal  since  the  1968  COBOL  standard.  COBOL  added 
separate  compilation  in  1974. 

Other  goals  in  the  1968  COBOL  standard  are: 

Expandability 

Problem  orientation  (to  data  processing) 

Machine  independence. 

The  following  chart  facilitates  a  comparison: 

Goal  Ada  COBOL 

Reliability  X 

Readability  X  X 

English-like  X  X 

Error  resistant  notation  X 
Separate  compilation  X  (provided) 

Programming  as  a  human 
activity  X 


Efficiency  X  X 
Expandability  X 
Problem  Orientation  X 
Machine  Independence  X  X 


(Implicit) 


Hoare  disputes  the  goal  of  facilitating  future  expansion 
[H0AR73J.  Yet  COBOL  explicitly  provides  for  expansion  by  its  eleven 
module  structure  and  provision  for  implementation  in  2  or  3  stages. 
Thus  COBOL  is  actually  a  family  of  languages  under  a  common  name 
IKREK79J.  This  situation  is  at  odds  with  the  goal  of  portability. 

Ada,  in  contrast,  discourages  modifications.  Revised  Ironman 
[IR0N74]  decrees,  ’’There  shall  be  no  subsc.:  o*  superset 
implementations."  To  a  large  extent  the  success  of  .n*  concept  will 
depend  on  the  degree  of  enforcemjnt  by  DoD.  The  road  may  be  bumpy, 
because  many  other  HOL's  have  over  a  period  cf  time  developed  into  a 
class  of  languages  sharing  the  same  name.  Krekel  cannot  resist  noting 
the  analogy  of  a  single  disease  which  encompasses  a  collection  of  sym¬ 
ptoms  [KREK79J. 

The  Ada  Reference  Manual  [ADA  80J  cites  several  subgoals  based  on 
consideration  of  programming  as  a  human  activity: 

-  to  develop  as  few  concepts  as  necessary. 

-  to  avoid  excessive  involutions  of  the  few  concepts. 

-  to  develop  language  constructs  which  correspond  to  the 
intuitive  expectations  of  the  programmer. 

The  first  two  subgoals  resemble  the  ALG0L63  major  objective  of 
"orthogonality",  but  the  last  may  be  unique  to  Ada.  There  is  no 
indication,  though,  of  just  how  the  programmer's  intuitive  expec¬ 
tations  will  be  met  JKREK79J. 

The  goals  of  safe  y  and  ease  of  training  are  not  claimed  by  Ada 
but  are  worthy  of  mention.  Safety  refers  to  the  ability  to  discover 
syntax  and  other  errors  before  they  result  in  more  serious  problems. 
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Ada  strong  typing  allows  the  compiler  to  determine  data  type  com¬ 
patibility,  precluding  serious  and  confusing  run  time  errors.  The 
idea  of  "type"  is  an  imposition  of  structure  on  data.  A  type 
describes  the  set  of  values  that  objects  of  the  type  may  take  on,  and 
the  set  of  operations  that  can  be  performed  on  them.  "Strong  typing" 
Is  a  characteristic  of  languages  which  rigidly  enforce  type  rules.  An 
example  of  enforcement  is  precluding  the  assignment  of  a  floating 
point  value  to  an  integer  variable,  unless  the  floating  point  value  is 
first  explicitly  converted  to  a  value  of  Integer  type. 

Pascal,  of  which  Ada  is  a  derivative,  embraced  training  as  a 
principal  design  goal.  The  idea  was  to  produce  a  language  "suitable 
to  teaching  programming  as  a  systematic  discipline"  [WIRT78].  Pascal 
appears  to  have  accomplished  this  goal,  since  it  is  now  commonplace  In 
the  undergraduate  curriculum.  The  jury  for  Ada  is  still  in  session, 
but  some  of  the  pioneers  have  had  some  difficulty  teaching  Ada.  The 
most  common  complaints  are: 

-  it's  tough  teaching  a  programming  language  which  has  no  com¬ 
piler 

-  Ada  has  so  many  features  that  it  takes  a  long  time  to  cover 

them 

-  Many  Ada  concepts  are  foreign  to  COBOL/FORTRAN  programmers, 
e.g.  packages,  tasks,  generics,  information  hiding,  user  defined 
types  and  strong  typing.  ' 

On  the  brighter  side,  most  educators  I  have  contacted  report  that 
students  are  enthusiastic  about  Ada  when  they  become  aware  of  Its 
advantages  as  a  design  tool.  Accordingly,  the  most  successful 


instructors  have  used  a  "give  the  big  picture  first"  approach.  For 
example,  LeBlanc  at  Georgia  Institute  of  Technology  introduces  Ada  via 
a  series  of  topics  related  to  overall  system  design  methodology: 
program  structure  (packages),  information  hiding,  abstract  data  types, 
separate  compilation,  management  of  program  development. 

Both  COBOL  and  Ada  claim  efficiency  as  a  design  goal,  but  without 
elaboration  on  how  to  achieve  it.  The  Ada  concept  was  to  examine 
every  proposed  construct  with  regard  to  present  implementation  tech¬ 
niques.  Any  construct  with  an  unclear  implementation  or  which 
required  "excessive"  machine  resources  was  rejected  [KREK79J. 

Krekel  criticizes  Ada  design  goals  on  these  issues  [KREK79]: 

1.  The  problem  domain  Is  unclear.  Reading  samples  from  the 
Rationale  for  Ada  [ICH79BJ  is  the  only  way  to  understand  the  Intended 
application. 

2.  Tradeoffs  between  design  goals  are  not  noted  In  Ada  reports, 

e.g. 

-  conciseness  of  language  definition  vs.  completeness  and 
understandabllity 

-  redundancy  vs.  providing  only  one  construct  for  each 

concept 

-  user  convenience  vs.  efficiency. 

3.  No  measures  are  provided  to  judge  accomplishment  of  the 
design  goal. 

DeMarco  C0EMA803  using  the  term,  "language  purity"  as  a  design 
Issue,  criticizes  Ada  for  extensions  to  Pascal  which,  though 
reasonable,  are  not  essential.  For  example: 
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-  Ada  built  in  type  STRING  (in  Pascal  you  can  define  your  own 
such  type) 

-  ASSERT  verb  (in  Pascal,  this  feature  could  be  user  defined) 

-  ELSEIF  (No  big  deal;  the  ELSE  IF  in  Pascal  does  as  well) 

-  The  RAISE  statement  (a  kind  of  Pascal  alias  for  GO  TO) 

The  conceptual  language  used  by  a  programmer  consists  of  the 
formally  defined  programming  language  plus  a  collection  of  user 
defined  tools  (extensions)  expressed  in  that  formal  language.  Ada 
anticipates  certain  programmer  needs  and  provides  a  number  of  tools 
which  are  left  to  the  programmer  by  Pascal.  According  to  DeMarco, 
anticipating  programmer  needs  is  almost  impossible,  so  the  spareness 
of  Pascal  is  a  better  approach.  A  lean  language  eases  implementation, 
training,  and  programming  £DEMA80J . 

Dijkstra  in  £DI JK78J  Issues  a  scathing,  rhetorical  indictment  of 
Ada  design  goals,  claiming  that  the  Department  of  Defense  didn't  know 
"what  it  was  asking  for,  and  why."  He  sees  Ada  as  a  misguided  attempt 
to  "improve  a  compromise" (Pascal )  by  insisting  that  Ada  better  accom¬ 
plish  conflicting  design  goals.  He  also  criticizes  the  apparent 
blurring  of  the  distinction  between  the  language  and  its 
implementation.  He  fears  that  Pascal  may  turn  out  to  be  an 
Improvement  over  its  successor  —  Ada. 

Overview  of  C080L 

At  the  highest  level,  a  COBOL  program  consists  of  four  divisions: 
IDENTIFICATION,  ENVIRONMENT,  DATA  and  PROCEDURE.  The  IDENTIFICATION 
Division  identifies  the  program  and  its  author.  The  ENVIRONMENT 


Division  prescribes  machine  dependent  characteristics.  It  must  be 
revised  if  the  program  is  transferred  to  a  new  machine. 

The  DATA  Division  allows  (and  requires)  the  programmer  to  define 
the  format  and  logical  structure  of  his  files,  records  and  variables. 
These  declarations  are  machine  independent  unless  special  machine 
dependent  data  representations  are  needed  for  efficiency.  For  exam¬ 
ple,  COMPUTATIONAL  representation  for  numeric  items  can  take  several 
different  forms,  depending  on  the  internal  machine  representation 
desired  by  the  programmer.  Most  data  are  defined  as  numeric  or 
character  (text)  format: 

77  EMPLOYEE_NUMBER  PICTURE  9999.  Numeric  format 
77  EMPLOYEE_NAME  PICTURE  XXXX.  Character  format 

Such  data  objects  are  considered  by  the  programmer  and  the  COBOL 
language  to  be  in  numeric/character  format  wherever  they  appear.  This 
form  of  data  object  declaration  helps  establish  easy  to  read  formats 
for  record  input/output.  Thus  the  DATA  Division  contains  declaration 
of  data  objects  and  their  types,  but  it  does  not  allow  type 
declarations  apart  from  data  objects. 

The  PROCEDURE  Division  contains  the  executable  statements  which 
are  to  be  performed  at  execution  time.  This  section  resembles  "the 
program"  in  a  language  like  FORTRAN  or  BASIC. 

COBOL  was  designed  to  automate  n.arjal  procedures  characterized  by 
a  series  of  small,  well  defined  operations  on  data  items.  This  is 
probably  the  rational'’  for  the  emphasis  on  COBOL  readability  at  the 
sentence  level  —  c  „  step  in  a  COBOL  program  can  be  described  in  a 
near-English  sentence,  e.  g. 
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ADO  OVERTIME  TO  NORMAL_EARNINGS  GIVING  TOTAL_EARNINGS. 

This  does  achieve  a  measure  of  readability,  but  many  modern  day 
language  experts  would  call  it  verbose.  Today  the  emphasis  in 
language  design  is  on  simplicity  and  generality  ("orthogonality"). 
COBOL  English- like  syntax  has  been  accomplished  largely  through 
liberal  selection  of  reserved  words,  about  300  in  all  CANSI74].  The 
"programning  by  selection  from  a  menu"  philosophy  is  resoundingly 
underscored  by  the  approved  addition  of  93  new  reserved  words  to  the 
next  revision  of  COBOL  [C0B080J .  Each  is  used  in  certain  contexts  to 
produce  a  quite  clear  result.  The  problem  with  this  is  that  elegance 
and  orthogonality  are  sacrificed  —  tr.:*  is,  there  are  numerous 
special  cases  or  exceptions  to  the  rule.  What  works  in  one  context 
does  not  in  another.  There  are  also  more  rules  to  learn.  Modern 
theory  extolls  the  importance  of  having  the  fewest  possible  features 
so  as  to  make  the  language  easier  to  master. 

Features  Ada  Implements  Directly:  Arithmetic 

The  comparison  of  Ada  and  COBOL  is  organized  in  four  categories: 
COBOL  features  Ada  provides  directly,  features  Ada  emulates,  Ada 
advantages,  and  things  Ada  does  not  do  well.  In  the  first  category  is 
arithmetic. 

Ada  syntax  does  not  provide  a  structure  to  compete  with  certain 
COBOL  English-like  arithmetic  statements,  such  as: 

ADD  OVER  TIME  TO  REGULAR  EARNINGS  GIVING  TOTAL  EARNINGS. 
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The  Ada  equivalent  is  simply  the  assignment  statement: 

TOTAL_EARNINGS  :=  OVERTIME  +  REGULAR JARNINGS 
1  nave  found  no  significant  evidence  to  support  or  detract  from  the 
importance  of  the  COBOL  approach.  Since  many  programming  languages 
seem  to  satisfy  users  with  the  assignment  statement,  I  conclude  that 
the  Ada  approach  is  satisfactory. 

COBOL  arithmetic  may  be  accomplished  most  succinctly  by  the  COM¬ 
PUTE  statement,  e.g. 

COMPUTE  OVERTIMEJARNINGS  =  ((HOURS  -  40.0)  *  1.5)  *  PAY_RATE . 

The  COMPUTE  statement  allows  assignment  of  the  value  of  an  arbitrarily 
complex  expression  to  the  variable  on  the  left  of  the  equals.  Ada 
provides  the  same  capability  with  the  assignment  statement,  e.g. 

OVERTIMEJARNINGS  :*  ((HOURS  -  40.0)  *  1.5)  *  PAY_RATE ; 

I  take  note  here  of  the  clearer  distinction  in  Ada  notation  between 
assignment  (:=)  and  boolean  operator  (*).  COBOL  uses  "="  for  both 
purposes. 

COBOL  provides  a  ROUNDING  option  (an  alternative  to  truncation) 
and  an  ON  SIZE  ERROR  option  which  provides  a  limited  programmer 
defined  exception  handling  capability.  For  example: 

COMPUTE  AMOUNT  ROUNDED  =  QUANTITY  *  PRICE  ON  SIZE  ERROR  PERFORM 
OF JRROR . 

Ada  can  emulate  this  feature  with  user  defined  functions  which  allow 
the  following  equivalrnt  statement: 

COMPUTE ( AMOUNT , QUANT I TY*PR ICE .ROUNDED ) ; 
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This  is  rather  awkward  and  is  not  recommended.  A  more  convenient  Ada 
solution  is: 

COMPUTE_ROUNDED( AMOUNT, QUANTITY  *  PRICE); 

Patter  yet,  perhaps  is  a  two  step  approach: 

AMOUNT  :=  QUANTITY  *  PRICE; 

ROUND (AMOUNT); 

Or,  one  final  variant: 

AMOUNT  :=  ROUND(QUANTITY  *PRICE); 

This  last  option  is  most  in  the  spirit  of  Ada. 

The  implementation  of  Ada  fixed  point  arithmetic  through 
assignment  statements  or  programmer  defined  functions,  as  in  the  above 
examples,  requires  a  solution  to  a  problem  of  types.  Multiplication 
and  division  of  fixed  point  values  produce  a  result  of  greater,  but 
undefined,  accuracy.  Thus  the  result  has  a  different  type  than  the 
operands.  Explicit  conversion  to  a  user-defined  fixed  point  type  is 
necessary.  Two  solutions  are  obvious.  One  approach  is  to  use  built 
in  type  conversion  functions  associated  with  user  defined  types: 

AMOUNT  :=  AMOUNT_TYPE(QUANTITY  *  PRICE); 

Another  idea  (which  Is  Impractical  in  large  programs)  is  to  overload 
the  and  '/'  operators  by  programmer  defined  implementations  which 
would  produce  a  result  having  the  same  type  as  the  operands: 
function  (X,Y  :  AMOUNT_TYPE)  return  AMOUNT_TYPE; 
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This  provides  the  illusion  of  implicit  type  conversion,  but  functions 
for  and  '/'  would  have  to  be  defined  for  every  fixed  point  type  In 
the  program.  Alternatively,  the  problem  could  be  solved  by  a  generic 
program  unit  (see  the  section  on  abstraction  for  an  explanation  of  the 
Ada  package): 

generic 

type  FIXED  is  delta  <>; 
package  FIXED_P0INT_0PN  is 
function  (U,V  :  FIXED)  return  FIXED; 
function  '/'  (U,V  :  FIXED)  return  FIXED; 
end  F I XED_P0I NT_0PN ; 

Given  one  declaration  of  **’  and  ’/’  functions  for  generic  fixed 
point  types,  the  prograimier  must  instantiate  the  functions  for  the 
particular  fixed  point  types  used  in  the  program: 

PAY_TYPE_OPN  is  new  FIXED_POINT_OPN(PAY_TYPE) ; 

T0TAL_C0ST_TYPE_0PN  is  new  FIXED_POINT_OPN(TOTAL_COST_TYPE) ; 

Even  now  there  are  user  defined  operations  only  for  operands  of  the 
same  type.  Mixing  different  types  in  a  multiplication  or  division 
operation  still  requires  an  explicit  type  conversion,  e.g.: 

P  :  PAY_TYPE; 

T  :  TAX_RATE_TYPF; 

•  •  • 

TAX  :«  PAY_TYPE(T)*P; 
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The  formerly  presented  method  of  explicit  conversion  would  be 
preferred  by  most  programmers,  since  it  contributes  to  readability  and 
simplicity. 

The  COBOL  exception  handling  option  ON  SIZE  ERROR  is  associated 
with  the  statement  generating  the  exception.  Ada  exception  handling 
facilities  are  more  extensive  and  are  discussed  elsewhere.  Since 
exception  handlers  in  Ada  are  associated  with  a  program  unit,  there 
can  be  one  set  of  arithmetic  exception  handlers  at  the  highest  level. 
Alternatively  the  programmer  can  include  a  handler  in  any  program  unit 
which  contains  arithmetic  statements. 

Records 

One  of  the  most  important,  extensively  used  COBOL  features  is  the 
record  and  its  associated  operations,  particularly  the  MOVE,  READ  and 
WRITE.  Records  associated  with  files  (and  hence  the  READ  and  WRITE 
operations)  will  be  discussed  later  as  part  of  the  I/O  features,  but 
for  the  moment  the  focus  is  on  "working  storage"  records.  Scalar 
variables  and  records  may  be  declared  in  the  working  storage  section. 
In  analogous  fashion  to  the  declaration  of  variables  and  records  in 
Ada.  COBOL  has  a  fixed  menu  of  data  types  which  may  not  be  extended 
by  the  user.  These  are  not  types  in  the  modern  sense;  they  merely 
allow  a  hlerarchlal  structuring  (of  elementary  items)  which 
corresponds  to  a  character  string.  User  defined  types  are  not 
allowed.  Available  COBOL  types  may  be  described  by  the  following 
diagram: 


There  is  another  important  distinction  from  modern  types:  the 
compiler  does  not  prevent  type  violations.  Run  time  checking  is 
necessary,  and  many  checks  are  generated  by  the  compiler.  Yet  COBOL 
lacks  features  which  would  assist  the  programmer  in  doing  the  job. 
Some  type  violations  may  escape  both  compile-tirre  and  run-time  checks. 
For  example,  the  declaration 
77  EMP10YEE_NUMBER  PICTURE  9999. 

does  not  prevent  transferring  'DUMB',  a  non-numeric  character  string, 
to  EMP10YEE_NUMBER  ol  run  time.  The  programmer  could  Insert  his  own 
type  checking  statement  to  determine  whether  the  transfer  is  legal. 
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e.g. 

IF  EMPLOYEE_NUMBER  IS  NOT  NUMERIC  PERFORM  TYPE_ERR_ROUTINE. 

This  paper  is  not  intended  to  indict  COBOL,  so  let  us  observe  the 
brighter  side,  that  for  the  supported  data  types  COBOL  provides  a  con¬ 
venient  syntax  for  data  definition. 

In  COBOL,  records  may  be  defined  in  hierarchial  fashion,  with 
"group  names"  referring  to  a  collection  of  subordinate  elements.  The 
Ada  record  is  quite  similar.  Examples: 

COBOL 

01  TIME_CARD. 

03  EMPLOYEE_DATA. 

05  EMPLOYE£_NO  PICTURE  9(4). 

05  EMPLOYEE_NAME  PICTURE  X(20). 

03  N0RMAL_EARNINGS  PICTURE  999V99. 

03  OVER  TIME  PICTURE  999V99. 
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types) 


Ada  (using  type  definition  and  anonymous 

type  TIME_CARD_TYPE  is 
record 

EMPLOYEE_DATA  :  record 

EMPLOYEEJO  :  INTEGER  range  0  ..  9999; 

EMPLOYEE_NAME  :  STRING(1  ..  20); 
end  record; 

N0RMAI_EARNINGS  :  delta  .01  range  0.0  ..  999.99; 

OVERTIME  :  delta  .01  range  0.0  999.99; 
end  record; 

TIME_CARD  ;  TIMEjCARO_TYPE; 

The  above  definition  is  remarkably  similar  to  that  of  COBOL,  but  the 
following  declaration  is  more  in  the  spirit  of  Ada,  and  it  avoids 
redundant  anonymous  type  declarations. 

K 

* 

♦ 

? 

1 


I 

« 
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Ada  (using  type  definition  _-  ail  types  named) 

type  EMPLOYE £_N0_TY P £  is  INTEGER  range  0  ..  9999; 
type  EMPLOYEE_NAME_TYP£  is  STRING(1  ..  20); 
type  EMP LOY EE_DAT A_T YP E  is 
record 

EMPL0YEE_N0  :  EMP LO Y EE_N0_TY P E ; 

EMPLOYEE_NAME  :  EMPLOYEE_NAME_TYPE ; 
end  record; 

type  N0RMAL_E ARN I NGS_TY P E  is  delta  .01  range  0.0  ..  999.99; 
type  TIME_CARD_TYPE  is 
record 

EMPLOYEE_DATA  :  EMPLOYEE_DATA_TYPE; 

NORMAL_EARNINGS  :  NORMAL_EARNINGS_TYPE; 

OVERTIME  :  NORMAL_EARNINGS_TYPE; 
end  record; 

•  •  • 

TIME_CARD  :  TIME  CARO  TYPE; 


Use  of  named  constants  further  enhances  the  Ada  declaration  by 
increasing  readability  and  expediting  later  changes  to  type 
definitions.  Example: 
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EMPLOYE E_NO_MAX I MUM  :  constant  INTEGER  :=  9999; 

EMPLOYEE_NAME_MAXLENGTH  :  constant  INTEGER  :=  20; 

NORMAL_EARN I NGS_MAX I MUM  :  constant  :=  999.99; 

type  EMPL0YEE_N0_TYP£  Is  INTEGER  range  0  ..  EMPLOYEE_NO_MAXIMUM; 

type  EMP LOY EE_NAME_T Y P E  is  STRING  (1  ..  EMPLOYEE_NAME_MAXIMUM) ; 

type  N0RMAL_E ARN I NGS_TYPE  is  delta  .01  range  0.0  ..  NORMAL_EARNINGS_MAXIMUM 

The  remainder  of  the  declaration  is  the  same  as  the  previous  example. 
Notice  the  progressive  approach  available  in  Ada  for  type 
declarations.  More  complicated  types  can  be  defined  in  terms  of 
constants  and  other  previously  defined  types.  The  programmer  may 
easily  change  a  type  definition  even  if  it  has  Impact  throughout  the 
program.  For  example,  redeclaring  EMP10YEE_NAME_MAXLENGTH  achieves 
the  desired  change,  even  though  numerous  types  and  variables  depend  on 
this  Item. 

The  Ada  package  may  also  be  used  to  declare  a  data  object. 

Ada  (using  package) 

package  TIME_CARD  is 
EMPL0YEE_DATA  :  record 

EMPLOYEEJO  :  INTEGER  range  0  ..  9999; 

EMPLOYEE_NAME  :  STRING  (1  ..  20); 
end  record; 

NORMALJARNINGS  :  delta  .01  range  0.0  ..  999.99; 

OVERTIME  :  delta  .ul  range  0.0  ..  999.99; 
end  TIME  CARO; 
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Reference  to  COBOL  and  Ada  record/package  elements  is  similar  as  the 
examples  below  point  out.  The  Ada  references  are  correct  for  all  the 
above  example  declarations. 

COBOL  Reference  to  Record  Element 
EMPL0YEE_N0  of  EMPLOYEE_DATA  of  TIME_CARD 

(Note:  If  element  names  are  unique  the  above  may  be  abbreviated  to: 
EMPLOYE E_N0) 

Ada  Reference  to  Record/Packaqe  Element 
TIME_CARD . EMP  LOYEE_DATA . EMPLOYEE _N0 

Note:  The  clause  "use  TIME _ CARD"  allows  a  reduction  in  qualification: 

EMPLOYEE_DATA.EMPLOYEE_NO. 

Further  reduction  is  possible  with  "use  TIME_CARD.EMPLOYEE_DATA" 
which  allows  the  same  abbreviation  as  the  COBOL  example: 

EMPL0YEE_N0  . 

One  disadvantage  of  the  package  as  a  data  structure  is  that  there  is 
no  built  in  way  to  access  or  manipulate  the  data  structure  as  a  whole, 
and  there  is  no  way  to  define  more  than  one  object  of  the  same  type. 

Unlike  the  Ada  package  example  and  the  COBOL  record,  the  Ada  type 
definition  does  not  establish  a  data  object.  Therefore  it  is  not 
meaningful  (and  is  illegal  in  Ada)  to  use  a  type  name  in  the  role  of  a 
variable.  Instead,  a  type  declaration  creates  the  format  of  a  data 
object,  allowing  subsequent  creation  of  objects  of  that  particular 
type  (format). 
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type  EMPLOYEE_NO_TYPE  Is  INTEGER  range  0  ..  9999; 

EMPLOYEE_NO_TYPE  :=  56;  --  Illegal  — 

An  advantage  of  the  type  name  is  the  ability  to  declare  any  number  of 
different  data  objects  of  each  type.  In  a  COBOL  application  requiring 
numerous  record  definitions,  this  ability  could  be  used  as  a  valuable 
shorthand,  readability  and  error  prevention  feature.  Record  elements 
Intended  to  have  the  same  type  can  be  so  declared  by  referring  to  the 
appropriate  type  name.  Consider  the  following  example,  where  the 
EMPLOYEE_NORMAL_EARNINGS_TYPE  is  needed  in  several  different  record 
types: 

EMPLOYEE_NORMAL_EARNINGS_TYPE  Is  delta  .01  range  0.0  ..  999.99; 
type  SPEC IAL_EARN I NGS_TYPE  is 
record 

EMPLOYEEJONUS  :  EMPL0YEE_N0RMAL_EARN I NGS_TYPE ; 

•  •  • 

end  record; 

type  MONTHLY_STATISTICS_TYPE  is 
record 

EMPLOYEE  JWG_SALARY  :  EMPLOYEE_NORMAL_EARNING$_TYPE; 

•  •  • 

end  record; 


This  Ada  feature  greatly  simplifies  changes  of  record  format. 


particularly  when  one  needs  to  alter  a  single  record  element  type 
which  appearc  in  numerous  different  records  (this  is  a  common  situa¬ 
tion  in  COBOL  programs). 

COBOL  allows  initialization  of  working  storage  records,  a  feature 

often  used  to  establish  titles  and  labels: 

\ 

COBOL  Record  With  Initial  Values 
01  T I ME_C AR  D_L I ST_T I TL  £ . 

03  FILLER  PICTURE  X(20)  VALUE  SPACES. 

03  FILLER  PICTURE  X( 15)  VALUE  'EMPLOYEE  NUMBER'. 

03  FILLER  PICTURE  X(5)  VALUE  SPACES. 

03  FILLER  PICTURE  X( 13)  VALUE  'EMPLOYEE  NAME'. 

03  FILLER  PICTURE  X(7)  VALUE  SPACES. 

03  FILLER  PICTURE  X(15)  VALUE  'NORMAL  EARNINGS'.  \ 

03  FILLER  PICTURE  X(5)  VALUE  SPACES. 

03  FILLER  PICTURE  X( 17)  VALUE  '0VrRTIME  EARNINGS'. 

Ada  has  a  corresponding  means  of  initializing  package  data  objects  and 
establishing  default  initialization  of  data  types: 
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Ada  Data  Type  With  Initial  Values 
Function  SPACES(HOW_MANY  :  INTEGER)  return  STRING; 
type  T I ME_C ARD_L I ST_T I TL E_TY P E  is 
record 

FILLER1  :  STRING(1  ..  20)  :=  SPAC£S(20); 

FILLER2  :  STRING(1  ..  15)  :=  'EMPLOYEE  NUMBER'; 

FILLER3  :  STRING(1  ..  5)  :  =  SPACES(5); 

FILLER4  :  STRING(1  ..  13)  :=  'EMPLOYEE  NAME'; 

FILLER5  :  STRING(1  ..7)  :=  SPmCES(7); 

FILLER6  :  STRING(1  ..  15)  :=  'NORMAL  EARNINGS'; 

FILLER7  :  STRING(1  ..  5)  :=  SPACES(5); 

FILLER8  :  STRING(1  ..  17)  :=  'OVERTIME  EARNINGS'; 
end  record; 

•  •  • 

TI ME_CARD_L I ST_T ITLE  :  TIME_CARD_LIST_TITLE_TYPE; 

Notice  the  use  in  the  above  example  of  a  programmer  defined  func¬ 
tion  to  handle  the  built  in  COBOL  literal  SPACES.  My  convention  in 
this  paper  is  not  to  define  the  inner  workings  of  functions  and 
procedures  so  as  not  to  distract  the  reader  with  details.  COBOL  has 
several  built  in  literals  to  simplify  the  programmer's  coding  job  and 
contribute  to  readability.  The  COBOL  VALUE  clause  also  allows 
initialization  of  variables  in  the  data  declaration  to  any  constant 
value.  The  Ada  function  Is  a  much  more  powerful  technique  since  It 
allows  similar  benefits  for  any  string  of  characters  desired  —  not 
just  spaces.  The  only  difference  from  COBOL  literals  appears  to  be 
the  need  to  specify  the  length  of  the  string  of  characters  required. 
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This  is  not  significant,  for  the  necessary  number  has  already  been 
specified  earlier  in  the  statement.  Use  of  the  SPACES  function 
elsewhere  in  the  Ada  program,  as  In  an  assignment  statement,  requires 
the  programmer  to  be  aware  of  the  size  of  the  string  to  which  charac¬ 
ters  are  being  transferred. 

Ada  Package  With  Initial  Values 
package  T I ME_C ARD_L I ST_T I TL E  is 
FILLER1  :  STRING  (1  ..  20)  :=  SPACES(20); 

•  •  • 

FILLER8  :  STRING(1  ..  17)  :=  'OVERTIME  EARNINGS'; 
end  TIME_CARD_LIST_TITLE ; 

The  FILLER  name  is  used  in  COBOL  to  designate  an  anonymous 
variable,  one  which  the  programmer  has  no  need  to  reference.  It  is 
commonly  used  in  the  definition  of  record  elements.  Ada  has  no 
corresponding  reserved  word,  but  its  visibility  rules  provide  a 
similar  convenience.  COBOL  needs  the  FILLER  feature  to  avoid 
unintentional  naming  conflicts,  since  with  few  exceptions  all 
variables  are  global.  In  Ada  a  record  element  name  will  not 
accidently  "hide"  or  conflict  with  another  as  It  would  In  COBOL. 
Example: 


COBOL  Naming  Conflict 


01  T IME_CARD_DETA I L_L  I NE . 

03  EMPLOY EE_NAME_P ICTURE  X(20). 

03  EMPL0YEE_T0TAL_EARNIN6S  PICTURE  999.99. 

•  •  • 

77  EMPLOYEE_TOTAL_EARNINGS  PICTURE  99.99. 

MOVE  25.00  TO  EMPLOYEE_TOTAL_EARNINGS. 

(Note:  At  this  point  in  the  program  we  have  conflicting  names 

visible) . 

Ada  programs  consist  of  one  or  more  modules.  Identifiers  declared 
in  a  module  are  local  to  that  module.  The  programmer  is  free  to  ignore 
identifiers  declared  externally  unless  he  needs  to  use  them.  When  he 
wishes  to  use  "imported"  names  he  can  consciously  avoid  hiding  them 
with  local  redeclarations.  This  is  a  simplistic  explanation  of  Ada 
visibility  (scope)  rules  (see  [ADA  80]). 

Features  Ada  Emulates:  The  COBOL  MOVE 

A  1980  AIRMICS  Software  Science  project  [GABR80]  includes  the 
analysis  of  production  COBOL  programs  using  an  automated  COBOL 
analyzer  developed  at  Purdue  University.  One  of  the  (not  surprising) 
findings  is  that  the  MOVE  statement  is  one  of  the  most  used.  The  MOVE 
in  COBOL  does  much  of  the  job  of  the  assignment  statement  in  other 
languages.  MOVE  is  perhaps  most  frequently  used  to  transfer  contents 
of  records  (either  in  their  entirety  or  by  components)  to  other 
records.  COBOL  associates  with  MOVE  an  elaborate  automatic  type  con¬ 
version  facility  as  indicated  in  the  following  table  [ANSI74J: 
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Category  of  Receiving  Data  Item 


Category  of 
Sending  Data 
Item 

Alphabetic 

Alphabetic  Edited 
or  Alphanumeric 

Numeric  Non-Integer 
Numeric  Edited 

Alphabetic 

yes 

yes 

no 

Alphanumeric 

Alphanumeric 

Edited 

yes 

yes 

no 

Numeric 

Integer 

no 

yes 

yes 

Numeric 

Non- Integer 

no 

no 

yes 

Numeric 

Edited 

no 

yes 

no 

Ada  is  perhaps  at  the  other  extreme  with  regard  to  automatic  type 
conversion.  This  is  no  accident,  because  the  technical  requirements 
for  Ada  specified  f IR0N79J :  "There  shall  be  no  Implicit  conversions 
between  types."  Differences  in  range,  precision  and  scale  are  not 
construed  as  differences  in  type,  yet  there  is  no  implicit  truncation 
or  rounding  in  integer  and  fixed  point  computations.  Thus  explicit 
conversion  is  necessary  to  constrain  the  result  of  a  fixed  point  mul¬ 
tiply  or  divide  to  the  same  type  as  the  operands. 

A  number  of  language  design  experts  support  the  Ada  approach,  but 
seasoned  FORTRAN  and  COBOL  programmers  may  cry  In  anguish  over  the 
tedium  of  worrying  about  what  they  perceive  are  unimportant  details 
about  data  types.  Though  it  seems  rather  autocratic,  Wirth  EWIRT74J 
advocates  giving  programmers  what  they  need  to  solve  their  problems, 
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not  what  they  say  they  want,  because  many  programmers  would  insist  on 
(perish  the  thought)  typeless  operands.  Hoare  [H0AR73J  reinforces 
Wirth's  emphasis  on  the  value  of  strong  typing  by  advocating,  "the 
complete  avoidance  of  any  form  of  automatic  type  transfer,  coercion, 
or  default  convention." 

Gannon  and  Horning  [GANN75J  preach  the  virtue  of  redundancy  as  In 
type  declarations.  They  demonstrate  the  great  contribution  to 
readability,  error  detection  and  program  reliability.  The  context  of 
each  use  of  a  data  Item  can  be  checked  by  a  compiler  for  agreement 
with  its  declared  type.  Ability  to  declare  restrictions  of  variables 
to  subranges  of  a  parent  type  (as  in  Ada)  allows  the  compiler  to 
optimize  storage  allocation  and,  more  important,  permits  easy  detec¬ 
tion  of  violations  at  run  time'  which  could  otherwise  be  difficult 
logic  bugs. 

Suppose  a  "COBOL  to  Ada  convert"  does  not  care  what  the  language 
design  experts  think.  Suppose  he  insists  on  the  next  best  thing  to 
automatic  type  conversion  that  Ada  can  offer.  He  should  then  consider 
(extensively)  overloading  a  programmer  defined  MOVE  procedure.  MOVE 
could  take  the  general  form: 

MOVE(SOURCE_NAME,DESTINATION_NAME); 

Generic  packages  can  be  used  to  advantage  i-ere,  but  a  separate 
Instantiation  will  be  necessary  for  ea^h  combination  of  operand  types 
(source  and  destination)  which  may  occur  in  the  program.  A  rather 
tedious  chore,  this  method  will  nonetheless  make  our  COBOL  diehard 
happy.  Let  us  consider  an  example  Implementation  of  a  MOVE  using 
fixed  point  source  and  destination.  Assume  the  following 
declarations: 
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type  NORMAL_EARN INGS_TYPE  is  delta  .01  range  0.0  ..  999.99; 
type  H I GH_PR EC I S 1 0N_T  Y P E  is  delta  .0001  range  0.0  ..  999.999; 

NORMAL  JARNINGS  :  NORMAL JARNINGS_TYPE; 

YEAR_TO_DATEJWERAGE  :  HIGH_PRECISION_TYPE; 

Implementation  of  the  move  could  take  this  form: 
generic 

type  SOURCE_TYPE  is  delta  <>; 
type  DESTINATION_TYPE  is  delta  <>; 
package  FIXED_POINT_MOVE  is 

procedure  M0VE(S  :  in  SOURCE_TYPE,  D  :  out  DESTINATIONJ7PE); 
end; 

package  body  FIXED_POINT_MOVE  is 
D  :=  DESTINATION_TYPE(S); 
end; 

To  instantiate,  we  use  declarations  like: 
package  M0VE1 

is  new  FIXE0_P0INT_M0VE(S0URCE_TYPE  =>  NORMAL_EARNINGS_TYPE, 

0ESTINATI0N_TYPE  *>  HIGH_PRECISION_TYPE) ; 

package  M0VE2 

is  new  FIXED_POINT_MOVE(SOURCE_TYPE  ->  HIGH_PRECISION_TYPE, 

DESTINATION_TYPE  ->  N0RMAL_E ARN I NGS_TY P E ) 
Now,  finally,  the  programmer  may  use  the  MOVE  procedure  In  either 
direction  and  achieve  the  desired  type  conversion: 
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MOVE ( NORMAL_EARN I NGS  ,  YEAR_TO_DATE_AVERAGE) ; 

MOVE ( YEAR_TO_DATE_AVERAGE  ,  NORMAL_EARNINGS) ; 

Even  though  multiple  definitions  of  MOVE  will  exist,  the  compiler  will 
select  the  proper  one  by  examining  the  types  of  the  operands. 

Consider  the  impracticality  of  this  approach.  To  provide  for  all 
possible  moves  to/from  each  type,  the  number  of  MOVE  procedure  in¬ 
stantiations  will  be  proportional  to  the  square  of  the  number  of 
data  types.  (100  data  types  =>  about  10,000  MOVE  instantiations!) 
One  could  develop  a  utility  program  to  scan  an  Ada  program  and 
automatically  generate  appropriate  MOVE  instantiations  to  handle  all 
possibilities.  A  more  reasonable  alternative  is  programner  instan¬ 
tiation  of  MOVE  procedures  on  an  "as  necessary"  basis. 

An  even  better  idea  is  to  remain  aware  of  operand  types  used  in 
the  program  and  employ  Ada  built  in  type  conversion  functions.  For 
example  the  previous  moves  could  be  accomplished  using  just  the  fol¬ 
lowing  statements: 

YEARJTOJJATEJWERAGE  :=  H I  GH_PR  EC  I S 1 0N_TY  P  E  ( NORMAL_EARN  I  NGS ) ; 
NORMALJARNINGS  :=  N0RMAL_E ARN I NGS_TYP E ( Y EAR_TO_DATE_AVERAGE ) ; 

The  COBOL  "alphanumeric  MOVE"  can  be  handled  in  Ada  in  similar 
fashion  to  the  "fixed  point  MOVE"  previously  described.  An  Instantia¬ 
tion  of  an  overloaded  MOVE  procedure  would  be  necessary  for  each  com¬ 
bination  of  strings  of  various  lengths.  Built  in  type  conversion 
functions  could  also  be  used. 


COBOL  also  allows  MOVE  of  a  numeric  Item  to  an  alphanumeric  Item. 
In  Ada  this  corresponds  to  a  move  of  an  Integer,  fixed  point  or  float¬ 
ing  point  type  to  a  string  type.  Built  in  type  conversion  will  not 
suffice.  The  best  way  to  accomplish  this  MOVE  seems  to  be  the  generic 
package  with  multiple  instantiations.  Example: 

type  NORMAL_EARNINGS_TYPE  Is  delta  .01  range  0.0  ..  999.99; 
type  NORMAL_EARNINGS_DISPLAY_TYPE  is  STRING(1  ..  20); 

NORMAL_EARNINGS  :  N0RMAL_EARN I NGS_TYPE ; 

N0RMAL_EARN I  NG$_D  I SP  LAY  :  NOR  MAL_E ARN I NGS_D I SP  LAY _TY  P  E ; 

We  want  to  implement  MOVE  such  that 

MO VE ( NORMAL_EARN I NGS , NORMAL_EARN I NGS_D  I SP  LAY ) 
will  accomplish  the  fixed  point  to  string  conversion, 
generic  package  could  do  the  job: 

generic 

type  FIX_TYPE  is  delta  <>; 

type  STR I NG_0B JECT_TYPE  Is  STRING (NAT URAL  range  <>); 
procedure  MOVEJT(FIX_SOURCE:  In  FIX_TYPE; 

STRING_OESTINATION:  In  out  STRING  _OBJECT_TYPE)  Is 

begin 

STRINGIEST  INATION  :«  F I  X_TYPE '  I  MAGE  ( F I  X_S0URCE ) ; 
end  MOVEJT; 

An  appropriate  instantiation  In  this  case  Is  procedure  MOVE  Is 
new  M0VEJT(FIX_TYPE  «>  NORMAL JARN I NGS_TYPE, 

STRING_OBJECT_TYPE  ■>  NORMAL_EARNINGS_TYPE) ; 


The  following 
* 
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This  is  an  appropriate  time  to  observe  what  may  already  be  obvious 
—  that  Ada  packages  and  other  constructs  provide  an  explicitly  coded 
solution  to  built  In  COBOL  features  which  are  implicitly  Implemented 
by  the  COBOL  compiler.  This  Ada  scheme  Introduces  an  extra  degree  of 
source  code  complexity.  The  unfavorable  impact  can  be  minimized, 
though,  by  the  provision  of  a  generous  set  of  predefined,  pretested, 
precompiled  Ada  packages  In  the  Ada  library  at  an  installation.  Ada's 
facilities  for  modular  programming  make  this  a  reasonable  approach. 
The  prograimter  need  only  be  aware  of  the  external  Interface  of  a  pac¬ 
kage.  Details  of  the  implementation  are  of  no  concern. 

Sort  Capability 

Next  to  the  record,  the  sort  capability  must  be  the  most  useful 
feature  for  business  data  processing.  Few  programs  indeed  can  do 
without  It.  In  COBOL  the  programmer  may  define  one  or  more  sort  files 
in  the  DATA  Division.  Example: 

SD  S0RT_FILE. 

•  •  • 

01  S0RT_REC_1. 

03  EMPLOYEEJJATAJ. 

05  EMPL0YEt_N0_S  PICTURE  9(4). 

05  EMPLOYEE_NAMES  PICTURE  X(20). 

03  NORMAL JEARN I NGS_S  PICTURE  999V99. 

03  OVER  TIME  S  PICTURE  999V99. 
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01  S0RT_REC_2. 

05  ACCOUNT_NUMBER_S  PICTURE  9(6). 

05  NAME_S  PICTURE  X(20). 

05  L0AN_AM0UNTS  PICTURE  9(5) V99. 

The  above  record  layouts  bear  suspicious  resemblance  to  those 
presented  later  In  the  discussion  of  records.  In  fact  they  are  the 
same  except  for  the  "S"  suffix  on  each  Identifier  for  readability. 
This  allows  us  to  easily  sort  the  files  consisting  of  TIME_CARD  or 
L0AN_REC0RD  records  on  any  of  the  elements  of  the  records.  Example: 

SORT  S0RT_FILE  ON  ASCENDING  KEY  ACCOUNT_NUMBER_S  NAME_S 
USING  LOAN_MASTER_F I LE 
GIVING  NEW_MASTER_FILE . 

This  simple  command  does  a  big  job.  Including  opening  the  source  and 
target  files,  reading  the  source  file,  performing  the  specified  sort, 
and  storing  the  result  in  the  target  file. 

How  shall  Ada  compete  with  the  powerful  SORT  verb?  The  package 
comes  to  the  rescue.  Let  us  heed  modern  language  design  theory  which 
recommends  encapsulating  data  structures  and  the  operations  defined  on 
those  structures.  We  shall  resurrect  the  previously  defined  package 
which  Included  a  definition  of  the  LOAN_RECORD_TYPE  and  add  to  It  a 
procedure  to  sort  files  containing  records  of  that  type. 
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package  LOAN_MASTER_F  ILE_PACKAGE  Is 
type  LOAN_RECORD_TYPE  is 
record 

ACCOUNT  JIUM8ER  *  range  0  ..  999999; 

NAME  :  STRING(1  ..  20); 

L0AN_AM0UNT  :  delta  .01  range  0.0  ..  99999.99; 
end  record; 

type  UP_DOWN_TYPE  is  (ASCENDING,  DESCENDING); 

L0AN_REC0RD  :  LOAN_RECORD_TYPE ; 
procedure  WRITE  (RECORD  :  in  LOAN_RECORD_TYPE) ; 
procedure  READ(RECORD  ;  out  LOAN_RECORD_TYPE); 
procedure  S0RT( INPUT_FILE  :  in  FILE_NAME_TYPE; 

OUTPUT_FILE  :  out  FILE_NAME_TYPE; 

UP_D0WN  :  in  UP_DOWN_TYPE; 

ACCOUNT_NUMBER_SORT_PR I  ;  S0RT_0RDER  1; 

NAME_SORT_PRI  :  SORTJORDER  :=  2; 

LOAN_AMOUNT_SORT_PR I  :  S0RT_0RDER  :=  3); 
end  LOAN_MASTER_F I L  E_PACK AGE ; 

Below  is  a  sample  use  of  the  package: 

SORT(INPUT/ILE  «>  LOAN_TEMP_FILE, 

OUTPUTJILE  «>L0AN_S0RT_FILE, 

UP_D0WN  *>  ASCENDING, 

ACCOUNT_NUMBER_SORT_PR I  ->  2, 

NAME_SORT_PRI  ->  1); 

Notice  that  in  Ada  not  all  procedure  parameters  have  to  be  provided  in 
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the  call;  default  values  will  be  used  for  those  omitted.  The  above 
accomplishes  a  sort  of  the  LOAN_TEMP_FILE  using  the  ACCOUNT_NUMBER 
element  as  the  key.  This  is  not  a  particularly  elegant  solution  — 
there  must  be  something  much  better  —  but  It  does  come  close  to  the 
power  of  the  COBOL  SORT.  Except  for  the  package  body  (which  Includes 
details  of  the  SORT  procedure)  the  programmer  does  not  have  much  more 
work  to  do  than  in  COBOL  to  "set  up"  the  SORT  procedure  for  use.  The 
SORT  procedure  call  is  almost  as  convenient  to  use  as  the  COBOL  ver¬ 
sion  and  is  nearly  as  readable.  The  most  awkward  part  of  the  solution 
presented  here  is  the  need  to  assign  "priority  numbers"  to  the  record 
elements  instead  of  merely  listing  the  sort  key  and  defining  ascending 
or  descending  priority.  But  surely  a  clever  Ada  programmer  can 
improve  on  this  solution. 

Database  Considerations 

All  major  existing  standard  Army  MIS  are  based  on  sequential 
files,  based  on  the  magnetic  tape  storage  medium,  but  USACSC  is 
committed  to  Incorporating  DBMS  technology  in  new  systems  and  major 
rewrites.  New  systems  will  take  better  advantage  of  random  access 
storage  devices.  An  ongoing  large  scale  redesign  of  the  Standard 
Army  Financial  System  will  be  the  first  USACSC  attempt  at  Incor¬ 
porating  a  DBMS  In  a  large  MIS. 

An  attractive  benefit  of  COBOL  Is  the  existence  of  a  generous 
collection  of  COBOL  oriented  DBMS  and  database  development  tools.  The 
Data  Base  Task  Group  of  the  Conference  on  Data  Systems  Languages  has 
developed  a  data  definition  language  (DDL)  and  a  data  manipulation 
language  (DML)  which  are  compatible  with  COBOL.  Popular  existing 
COBOL-oriented  DBMS  Include  IMS,  TOTAL,  SVS200,  IDMS,  ADABAS  and 
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0MS-1100.  There  are  a  number  of  automated  tools  which  help  develop 
schemas  and  sub  schemas.  Many  produce  COBOL  Data  Division  code. 

In  time  there  will  be  DBMS  for  Ada.  One  ongoing  effort  to 
develop  an  Ada  oriented  DBMS  is  that  of  Computer  Corporation  of 
America,  sponsored  by  DoD  and  the  Navy  [P0TT80].  Called  ADAPLEX,  It 
provides  a  set  of  database  commands  to  be  embedded  in  Ada.  The 
database  facilities  will  be  designed  as  Ada  packages.  ADAPLEX  should 
be  available  in  the  mid  1980's.  Existing  COBOL-oriented  DBMS  and 
tools  can  be  adapted  to  Ada  in  a  straightforward  manner. 

Ada  Advantages:  Strong  Typing 

According  to  Gannon  [GANN76J  the  aim  of  reliable  programming  is 
to  reduce  the  number  of  errors  in  delivered  software.  This  goal  may 
be  achieved  by  preventing  programmer  errors  or  by  increasing  the  per¬ 
centage  of  errors  which  are  detected  and  corrected  before  the  final 
product  is  complete.  Strong  typing,  an  Ada  design  goal,  can  help  in 
both  departments. 

A  data  type  determines  what  operations  are  permitted  on  operands 
of  that  type.  The  two  biggest  advantages  of  data  types  are  abstrac¬ 
tion  and  authentication  £M0RR73J.  A  data  type  hides  the  implementa¬ 
tion  details  for  objects  of  that  type,  so  a  programmer  can  (and  must) 
deal  with  an  abstraction  which  facilitates  solving  the  problem  at 
hand.  The  programmer  can  deal  with  objects  like  "stack",  "matrix",  or 
"color"  rather  than  collections  of  machine  memory  words  or  bit  pat¬ 
terns  within  words.  Authentication,  often  called  type  checking, 
insures  that  Invalid  operations  cannot  be  performed  [GANN76J. 
For  example,  authentication  will  prevent  arithmetic  on  boolean 
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or  string  values.  Authentication  may  be  approached  several  ways  in  a 
programming  language:  static  type  checking,  dynamic  type  checking,  or 
no  type  checking. 

Ada  emphasizes  static  checking,  which  means  that  a  data  type  is 
permanently  associated  with  a  variable  when  It  is  declared,  and  that 
operations  are  checked  for  validity  at  compile  time.  Dynamically 
typed  languages  allow  the  type  of  a  variable  to  vary  during  program 
execution.  Generally  the  variable  type  Is  defined  as  the  type  of  the 
last  value  assigned  to  the  variable.  Typeless  languages  consider  each 
operand  as  a  bit  pattern  which  is  assumed  to  represent  a  value  of  the 
type  that  the  operator  requires.  Assembler  languages  are  usually 
typeless. 

COBOL  provides  for  declarations  of  variables  but  allows  their 
types  to  vary,  in  many  cases,  through  assignment  or  automatic  type 
conversion.  COBOL  seems  to  be  a  cross  between  dynamically  typed  and 
typeless,  but  Is  probably  best  characterized  as  dynamic,  since  the  few 
type  checks  that  are  made  are  deferred  until  run  time. 

Programmers  who  favor  dynamically  typed  languages  maintain  that 
they  are  flexible  to  use  and  easy  to  implement,  but  they  overlook  a 
serious  problem.  Type  violations  (operators  having  operands  of  the 
wrong  type)  may  be  checked  only  at  run  time.  Run  time  checks  tend  to 
slow  execution.  Worse,  a  run  time  check  only  detects  errors  In  code 
actually  executed,  so  a  type  violation  in  a  piece  of  code  not  exer¬ 
cised  during  testing  will  survive  to  later  plague  the  final  product 
(GANN78] . 


Advocates  of  typeless  languages  often  hail  their  allowing  the 
programmer  to  take  maximum  advantage  of  the  characteristics  of  the 
underlying  machine  [WIRT74J.  Wlrth  says  that  the  most  prevalent 
programing  trick  is  to  pack  several  different  kinds  of  data  into  a 
single  machine  word.  He  points  out  that  this  objective  can  more 
elegantly  be  accomplished  in  a  statically  typed  language  [such  as  Ada] 
using  a  record  structure. 

The  system  language  for  Project  SUE  [CLAR73]  is  a  good  example  of 
the  value  of  type  checking  in  operating  system  design:  type  checking 
was  the  most  valuable  logic  error  prevention  aid  in  the  project. 

Static  typing  is  effective  in  error  prevention.  The  declaration 
of  data  types  is  redundant,  since  the  implied  type  of  an  operand  may 
be  determined  from  the  context.  This  redundancy  is  advantageous, 
though,  because  it  allows  a  compiler  to  check  each  use  of  an  operand 
to  insure  that  the  operation  is  defined  for  the  declared  operand  type. 

Gannon  conducted  experiments  and  reached  the  conclusion  that 
statically  typed  languages  with  explicit  conversion  provide  early  and 
reliable  detection  of  errors  [GANN76],  He  observed  25  experienced 
programmers  each  solving  several  small  but  complex  programs.  The  two 
programming  languages  used  in  the  experiment  provided  static  typing 
for  some  data  types  and  dynamic  typing  for  others.  This  was  clearly 
documented  in  the  language  manuals.  Occurrences  of  errors  were  logged 
for  each  run.  Persistence  of  errors  of  a  certain  type  was  calculated 
as  the  number  of  occurrences  divided  by  the  number  of  errors  of  that 
type.  During  815  program  runs,  3937  occurrences  of  1248  errors  were 
recorded.  405  occurrences  of  116  errors  were  caused  by  operands  with 
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incorrect  data  types.  329  occurrences  (of  104  errors)  could  have  been 
precluded  by  compile  time  (static)  checking. 

Even  in  typed  languages  there  remains  the  alternative  of  explicit 
or  implicit  type  conversion,  COBOL  embellishes  the  latter.  and  this 
does  make  programing  faster,  since  little  attention  need  be  given  to 
type  compatibility.  But  Hoare  cites  several  disadvantages  of  Implicit 
conversion: 

-  Errors  are  often  masked  by  "nearly"  correct  results 

-  Run  time  overhead  is  a  significant  penalty 

-  Conversion  rules  complicate  the  language  definition. 

Certainly  COBOL  is  guilty  of  the  third  disadvantage.  For  proof,  take 
a  look  at  the  large  table  of  con*‘ers1on  rules  presented  earlier. 

Data  Abstraction 

Classical  linguistic  theory  has  established  that  the  kind  of 
language  we  use  affects  the  way  we  think  about  solving  problems 
[DILL77].  For  example,  a  FORTRAN  programmer  probably  seldom  thinks  of 
using  a  recursive  procedure  or  a  linked  list,  but  these  are  everyday 
tools  of  the  LISP  programmer  IWULF80J. 

Whether  during  development  of  a  large  programming  project  or  dur¬ 
ing  the  maintenance  phase,  the  most  important  factor  affecting  the 
difficulty  of  getting  the  job  done  Is  readability  of  the  code.  Ease 
of  writing  is  not  so  Important  {WULF80J.  To  understand  a  piece  of  a 
program  one  must  first  understand  what  the  program  Is  to  do,  and  most 
programing  languages  tend  to  emphu.' Ize  how  a  problem  was  solved 
rather  than  what  the  program  was  supposed  to  do.  Thus  It  Is  easier  to 
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understand  a  queuing  operation  when  it  is  defined  as  a  separate, 
abstract  operation  than  to  determine  that  a  sequence  of  statements 
modifying  arrays  happens  to  implement  a  queuing  operation  [WULF80J. 

A  programming  language  serves  three  purposes  [WULF80J:  a  design 
tool,  a  vehicle  for  human  communication,  and  a  means  of  instructing  a 
computer.  The  first  two  purposes  are  the  most  significant,  since  they 
relate  most  strongly  to  possible  reduction  of  costs  in  the  maintenance 
phase.  Over  half  the  total  cost  of  software  development  is  often 
attributable  to  maintenance.  As  we  shall  see,  data  abstraction 
facilities  are  very  helpful  in  improving  design  procedures  and  human 
communication. 

The  structured  programming  approach  was  adopted  by  USACSC  in  the 
1970's  in  an  effort  to  increase  reliability  of  systems  and  reduce 
development  and  (particularly)  maintenance  costs  [MITC80].  The  struc¬ 
tured  programming  concept  includes  a  disciplined  approach  to  system 
design,  a  management  scheme  and  a  methodology  for  programming 
[CARR78].  "Top  down  development"  is  a  core  philosophy.  Systems  are 
to  be  conceived  of  and  described  initially  as  a  set  of  high  level 
control  modules  and  functional  modules.  As  the  design  phase 
continues,  one  procedes  to  the  detailed  design  of  lower  level  func¬ 
tions.  There  appears  to  be  no  conceptual  difference  between  this  and 
Wirth's  "stepwise  refinement"  concept  [WIRT74J.  The  goal  is  to 
emphasize  overall  design  by  postponing  concern  over  details  of 
Implementation.  Structured  programming,  then,  should  take  advantage 
of  programming  language  features  related  to  Wulf's  first  two  purposes: 
a  design  tool  and  vehicle  for  human  communication. 


USACSC  has  a  heavy  investment  in  the  structured  programming 
approach  CCARR78]: 

-  defining  the  theory  and  concept  (1974-75) 

-  determining  how  to  apply  the  technology  in  USACSC  (1975-76) 

-  actual  conversion  to  the  approach  (1976-77). 

The  Division  Logistics  System  was  the  first  major  application  of 
structured  programming,  and  the  use  of  this  technology  was  deemed  a 
success  by  most  managers  and  programmers  [CARR78J. 

In  the  Procedure  Division  COBOL  provides  facilities  for  structure 
of  text  and  of  control.  Text  may  be  structured  by  concatenation  of 
sentences  into  paragraphs  or  paragraphs  Into  sections.  Control  struc¬ 
tures  include  [JACK76J: 

-  PERFORM  can  execute  a  paragraph  or  section  which  Is  not  "In 

line" 

-  PERFORM  can  provide  iteration  (While/Do/For) 

-  GO  TO  provides  transfer  to  the  start  of  a  paragraph  or  section 

-  GO  TO  DEPENDING  ON  gives  a  multiway  branch. 

The  above  features  are  collectively  Inadequate.  Designers  of 
COBOL,  like  those  of  most  older  programming  languages,  did  not 
consider  what  design  methodology  would  be  used  to  write  programs.  As 
a  result  COBOL  provides  few  aids  and  some  hindrances  to  designing 
large  systems  C0ACK76J.  For  example,  all  variable  names  are  global; 
there  Is  no  way  to  restrict  the  use  of  a  variable  to  a  particular 
procedure  CJACK76].  No  variable  Is  safe  from  access  or  alteration  by 
Instructions  in  any  part  of  a  program.  In  a  large  program  this  can 
create  the  same  sort  of  mystery  that  often  confronts  users  of  FORTRAN 
COMMON.  The  situation  Is  particularly  troublesome  to  those  attempting 
to  use  library  procedures. 
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Certainly  programming  language  data  abstraction  facilities  (such 
as  Ada  provides)  make  the  top  down  approach  easier  to  implement. 
Indeed  they  provide  significant  advantages  in  the  most  important 
aspects  of  program  development:  decomposition,  documentation  and 
modification  CLEBL80J .  LeBlanc  uses  the  term  "data  abstraction"  in  a 
broad  sense  which  includes  procedural  abstraction  as  well.  The  most 
important  step  in  program  development  Is  dividing  the  problem  into 
smaller  problems  which  are  easy  to  understand  and  program.  There  are 
many  ways  to  slice  a  pie,  but  an  effective  decomposition  of  a  program 
requires: 

-  a  natural,  "meaningful"  partitioning 

-  well  defined  interfaces  between  units 

-  hiding  the  details  of  the  units  from  one  another. 

The  natural  partitioning  depends  on  the  skill  of  an  experienced 
analyst,  but  languages  which  require  formal  definition  of  abstractions 
help  fulfill  the  other  two  requirements. 

The  Ada  package  Is  the  primary  building  block  of  Ada  programs. 
It  encapsulates  data  with  the  subprograms  which  operate  on  that  data, 
thus  specifying  a  collection  of  logically  related  computational 
resources.  A  package  Is  normally  stated  in  two  parts:  a  package 
specification  and  a  package  body.  The  specification  Is  the  descrip¬ 
tion  of  what  the  package  Is  supposed  to  do.  It  may  be  considered  a 
window  through  which  the  package  Is  to  be  viewed.  The  Ada  specifica¬ 
tion  has  all  the  Information  needed  to  use  the  facilities  of  the 
abstraction,  and  since  it  is  the  only  way  to  access  the  abstraction 
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the  details  are  hidden.  Consider  the  following  example  from  [BARN80J: 
package  STACK  is  —specification 

procedure  PUSH(X:REAL); 
function  POP  return  REAL; 
end; 

package  body  STACK  Is  —body 

MAX: constant  :*  100; 

S:array(l. .MAX  of  REAL; 

PTR: INTEGER  range  0..MAX; 
procedure  PUSH(X:REAL)  Is 
begin 

PTR  :=  PTR  +  1; 

S(PTR)  :=  X; 
end  PUSH; 

function  POP  return  REAL  Is 
begin 

PTR  :=  PTR  -  1; 
return  S(PTR  +  1); 
end  POP; 

Though  stacks  are  not  often  used  In  MIS  programs,  the  example 
Illustrates  many  key  features  of  the  Ada  package.  Notice  the  separa¬ 
tion  of  the  specification  and  body.  If  this  package  body  Is  precom¬ 
piled  and  only  the  source  code  for  the  specification  Is  available, 
then  users  of  the  package  may  employ  the  procedures  PUSH  and  POP  but 
they  need  not  know  about,  and  cannot  access,  details  of  the  stack 
Implementation. 
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In  many  cases  it  is  useful  to  provide  limited  access  to  a  data 
structure.  The  Ada  private  type  declaration  establishes  a  type  such 
that  objects  of  this  type  have  only  the  following  operations  defined 
on  them  outside  the  package  In  which  the  objects  are  declared: 
assignment,  and  The  most  restrictive  access  is  provided  by 

a  declaration  of  an  object  of  a  limited  private  type.  In  this  case, 
only  the  operations  explicitly  provided  by  the  programmer  may  be 
applied  to  the  object  outside  the  package  in  which  it  is  declared. 
The  following  adaptation  of  an  example  from  the  Ada  Reference  Manual 
Is  a  good  illustration: 
package  I_0  PACKAGE  is 
type  FILE_NAME  is  limited  private; 
procedure  0PEN(F:  in  out  FILE_NAME); 
procedure  CL0SE(F:1n  out  FILENAME); 
procedure  READ(F:  in  FILE_NAME;  ITEM:  out  INTEGER); 
procedure  WRITE(F:  In  FILE_NAME;  ITEM:  In  INTEGER); 
private 

type  FILE_NAME  is  INTEGER  :=  0; 
end  I_0_PACKAGE; 

package  body  I_0_PACKAGE  Is 
LIMIT  :  constant  :=  200; 
type  FILE_DESCRIPTOR  Is  record  ...end  record; 

DIRECTORY  :  array(l. .LIMIT)  of  FILE_DESCRIPTOR; 

•  •  • 

procedure  0PEN(F  :  in  out  FILE  NAME)  is  ...  end; 
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procedure  CL0SE(F  :  In  out  FILE _ NAME)  Is  ...  end; 

procedure  READ(F  :  in  FILE_NAME;ITEM:  out  INTEGER)  Is  ...  end; 
procedure  WRITE(F  :  In  FILE_NAME;ITEM:  In  INTEGER)  Is  ...  end; 
begin 
•  •  • 

end  I_0_PACKAGE; 

Given  the  above  package,  the  programmer  can  declare  objects  of 
type  FILE_NAME  and  can  get  a  value  for  an  object  of  this  type  by  using 
the  operation  OPEN.  The  operations  CLOSE,  READ  and  WRITE  are  also 
available. 

A_FILE  :  FILE_NAME;  -establishes  data  object 
X  :  INTEGER; 

•  •  • 

OPEN(A_FILE);  —gives  A_FIL£  a  value  and  opens  the 

—file  having  this  value 

The  programmer  cannot  access,  or  take  advantage  of  knowing,  the 

details  of  the  Implementation  of  FILE_NAME.  Therefore  the  package 

body  is  safe  from  tampering  or  abuse.  Suppose  a  programmer  found  out 

that  FILE_NAME  was  Implemented  as  an  Integer.  He  or  she  then  might 

attempt  the  following  statements,  all  of  which  are  Illegal  and  would 

be  flagged  by  the  Ada  compiler: 

A_FILE  :  FILE_NAME  :■  0;  —assignment  of  an  Initial  value 

—Is  not  an  operation  defined 
—for  type  FILE  NAME 

A_FILE  :*  3;  —assignment  noT  available 

A_FILE  :■  A_FILE  +  1;  —assignment,  addition  not  available 

IF  B_FILE  >  A_F I LE  then  ...  —boolean  operations  not  available 

The  above  examples  show  how  package  Implementation  details  are 


hidden  from  the  outside  world  and  are  safe  from  Intentional  or 
accidental  tampering,  particularly  clever  programming  tricks,  which 
lead  to  insidious  errors  and  portability  problems.  Perhaps  "hiding" 
Is  a  poor  choice  to  describe  this  phenomena,  since  some  software 
project  managers  believe  some  of  their  biggest  problems  spring  from 
Information  hidden  from  them  by  their  subordinates.  To  them, 

" Information  protection"  would  have  a  better  connotation. 

The  package  body  implements  the  package  specification.  The  two 
parts  may  be  separately  compiled  and  text  of  the  package  specification 
and  body  need  not  be  contiguous. 

Documentation  should  be  a.  continuous  process  during  development 
and  not  a  separate  phase  or  afterthought.  Leblanc  notes  the  important 
contribution  of  language  abstraction  facilities  to  the  "development  of 
well  structured  (self  documenting)  programs  using  stepwise  refinement" 
CLEBL80J.  This  is  the  top  down  approach,  which  calls  for  initially 
defining  high  level  abstractions  for  major  functions.  The  process  of 
implementing  these  abstractions  results  in  the  conception  of  more 
lower  level  abstractions,  and  the  process  continues  until  it  is 
reasonable  to  implement  the  abstractions  using  built  in  language 
features  or  to  take  advantage  of  existing  library  abstractions 
(LEBL80] . 

Using  Ada,  a  programmer  can  think  and  write  initially  in  terms  of 
package  specifications  in  order  to  sketch  a  solution  to  a  problem. 
The  details  of  implementation  (that  is,  the  package  bodies)  may  be 
deferred. 

Names  can  be  chosen  freely  in  each  packaqe.  For  example  there 
need  be  no  programmer  concern  for  using  INSERT  as  a  procedure  name. 


-55- 


even  if  it  has  been  used  before  as  a  procedure  name.  Even  if  two 
procedures  with  the  same  name  are  active  (visible)  at  some  point  In  a 
program  there  Is  no  conflict  as  long  as  the  procedure  parameter  types 
are  distinct,  as  In  the  following  case  £ICHB80J: 
procedure  INSERT* E: ELEMENT); 
procedure  INSERT* E: ITEM); 

In  the  rare  event  that  parameter  types  are  Identical,  then  qualifica¬ 
tion  or  the  RENAMES  option  can  resolve  naming  conflicts: 

procedure  INS£RT_QUEUE(E: ITEM)  renames  QUEUE. INSERT; 
procedure  INSERT_STACK(E:ITEM)  renames  STACK. INSERT; 

There  Is  no  aliasing  problem  here  as  there  Is  with  the  COBOL  RENAMES, 
for  the  original  (conflicting)  names  are  considered  Invalid  and 
Illegal.  In  COBOL  both  the  original  and  the  new  name  can  refer  to  the 
same  data. 

All  software  maintenance  actions  (fixes,  enhancements)  require  a 
program  to  be  changed.  The  ease  of  modification  Is  directly  related 
to  the  ability  to  localize  the  effects  of  the  change  JLEBL80].  The 
encapsulation  of  an  abstraction  such  as  the  Ada  package  greatly 
assists  In  this  localization.  The  formal  definition  of  the  abstrac¬ 
tion  (the  Ada  package  specification)  logically  separates  the  abstrac¬ 
tion  Implementation  from  other  program  units  which  use  It.  If  the 
Implementation  Is  wrong,  and  must  be  changed  to  comply  with  Its 
specification,  the  progranmer  may  amend  It  while  basking  In  the  con¬ 
fidence  that  he  Is  causing  no  unexpected  side  effects  outside  the 

*  i 

abstraction.  If  the  specification  must  be  changed,  then  so  must  Its 
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Implementation,  and  all  units  which  use  this  abstraction  may  need 
alteration.  But  there  will  be  fewer  changes  required  than  there  would 
if  other  units  accessed  the  Inner  workings  of  the  abstraction 
|LEBL80] . 

Most  progranwers  are  well  aware  of  the  advantages  of  procedures 
with  parameters.  They  allow  the  same  section  of  code  to  be  used  to 
process  more  than  one  set  of  data.  Parameterizing  abstractions 
extends  the  application  in  like  manner.  One  well  understood,  debug¬ 
ged,  general  purpose  abstraction  can  be  established  as  several 
different  Instances  by  varying  Its  parameters  tLEBL80].  This  requires 
less  code  and  less  mental  effort  than  creation  of  numerous  special 
case  abstractions.  Ada  generic  packages  provide  translation  time 
parameterization  using  a  general  package  definition.  Consider  the 
following  generic  package,  which  Is  a  generalized  version  of  the  stack 
package  presented  earlier  [BARN80]: 
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generic 
MAX: INTEGER; 
type  ELEM  is  private; 
package  STACK  Is 
procedure  PUSH( X : ELEM) ; 
function  POP  return  ELEM; 
end; 

package  body  STACK  Is 
S:array(l. .MAX)  of  ELEM; 


end  STACK; 

A  particular  Instance  of  a  stack  Is  declared  by  a  "generic 
instantiation"  which  provides  actual  parameters.  Example: 
declare 

package  REAL_STACK  Is  new  STACK(100,REAL); 

use  REAL_STACK;  —allows  shorthand  reference 

—to  PUSH  Instead  of  REAL_STACK.PUSH  | 

begin  1 

PUSH(X) ; 

... 

X  :*  P0P(); 
end; 

Both  the  size  of  the  stack  and  the  type  of  elements  contained  In  the 
stack  are  parameters,  so  this  piece  of  code  may  be  Instantiated  to 
satisfy  the  need  for  stacks  of  various  sizes  and  elements.  The  fol¬ 
lowing  code  takes  advantage  of  the  same  generic  package  STACK  to 
create  a  stack  of  50  records: 
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type  £MPLOYEE_R£C_TYP£  Is 

record 

•  •  • 

end  record; 

EMPLOYEE  :  EMPLOYEE_REC_TYPE ; 

package  EMPLOYEE_STACK  is  new  STACK ( 50, EMPLOYEE_REC_TYPE); 

Any  number  of  instantiations  of  the  generic  package  may  be  active  at 
the  same  time.  That  is,  we  can  use  REAL_STACK.PUSH(X)  to  Insert  a 
real  value  Into  the  REAL_STACK  and  EMP10YEE_STACK . PUSH( EMPLOYEE )  to 
Insert  a  record  in  the  EMPLOYEE  stack. 

Separate  Compilation 

The  ability  to  separately  compile  modules  further  increases  the 
benefit  of  data  abstraction.  In  particular  It  can  reduce  costs  of 
program  modification  [LEBL80J.  LeBlanc  points  out  three  relevant 
aspects  of  compilation  cost  saving.  First,  recompiling  only  affected 
modules  Instead  of  the  entire  program  saves  programmer  time  and  com¬ 
puter  time.  Second,  separate  compilation  facilitates  providing  a 
library  of  reusable  code.  Third,  perhaps  the  most  Important  cost  of 
"non- separate"  compilation  Is  Indirect.  Using  a  language  which  does 
not  facilitate  separate  compilation  conditions  the  programmer  to  think 
of  a  program  as  one  big  chunk  rather  than  a  collection  of  separate 
units  which  work  In  harmony  during  execution.  This  tends  to  foster 
the  bad  habit,  during  modification  and  new  design,  of  writing  a  single 
program  to  solve  the  whole  problem. 

The  CALL  statement  was  added  to  COBOL  In  1974  to  provide  separate 
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compilation  of  modules  and  to  achieve  the  effect  of  a  subroutine  with 
parameters.  Each  separately  compiled  module  must  be  a  complete 
program  with  all  4  divisions.  Data  Items  which  are  to  be  transferred 
between  two  compilation  units  are  listed  In  a  USING  clause  In  each 
unit.  Parameters  are  passed  by  reference;  that  Is,  any  reference  to  a 
parameter  name  in  the  called  module  actually  accesses  the  correspond¬ 
ing  parameter  name  In  the  calling  module.  Recursive  calls  to  a  module 
are  not  permitted.  Here  is  a  typical  example,  from  [TRIA75]: 

Calling  Module  Called  Module 


IDENTIFICATION  DIVISION.  IDENTIFICATION  DIVISION 

PROGRAM_ID.  CUST.  PROGRAMED.  CHECKDIG. 


DATA  DIVISION. 


DATA  DIVISION. 


WORKING_STORAGE  SECTION.  WORK I NG_STORAGE  SECTION. 

77  CUST  NO  PIC  X(10). 

77  CHAR?  PIC  99. 

LINKAGE  SECTION. 

77  CHARS  PIC  99. 

77  CODE  NO  PIC  9(10). 

PROCEDURE  DIVISION.  PROCEOUlfE  DIVISION. 


’’CALL  "CHECKDIG" 

USING  CUST_NO  CHARS. 


USING  CODE  NO  CHARS. 


In  the  above  example,  whenever  the  data  item  CODE_NO  Is  used  In  the 
called  module,  the  variable  CUST_NO  In  the  calling  module  Is  accessed. 

Ada  provides  more  flexibility.  A  compilation  unit  can  consist  of 
a  subprogram  declaration  or  body,  a  package  specification  or  body,  or 
a  generic  declaration.  Parameters  are  passed  by  value,  and  they  may 
be  specified  in  procedures  as  "In"  or  "out"  to  Indicate  the  direction 
of  data  transfer.  Recursive  calls  to  a  compilation  unit  are  permit¬ 
ted.  Ada  separate  compilation  provides  the  same  degree  of  type  check¬ 
ing  across  compilation  units  as  within  units.  Relationships  between 
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units  are  easily  established  using  WITH  clauses.  Version  control  will 
check  obsolescence  and  facilitate  top  down  development  [ICHB8O3. 

The  Ada  package  specification  and  package  body  are  maintained 
separately  by  the  library  facility,  and  a  program  which  uses  a  package 
depends  only  on  the  specification.  The  body  can  be  revised  and  recom¬ 
piled,  provided  it  continues  to  Implement  the  specification,  without 
changing  the  specification. 

Top  down  design  depends  on  extensive  use  of  modules  and  sub- 
modules.  In  Ada  one  can  easily  specify  the  existence  of  submodules 
while  delaying  the  details  of  Implementation  and  the  compilation  of 
the  submodule  until  later.  Revisiting  the  stack  provides  a  simple 
example.  A  good  top  down  programmer  might  initially  define  the 
overall  structure  of  STACK  with  the  following  package  body  [BARN80] 
which  declares  separate  subunits  for  the  operations  PUSH  and  POP: 
package  body  STACK  is 
MAX: constant  :=  100; 

S:array(l. .MAX)  of  REAL; 

PTR: INTEGER  range  0..MAX; 
procedure  PUSH(X:REAl)  Is  separate; 
function  POP  return  REAL  Is  separate; 
begin 
PTR  :=  0; 
end  STACK; 

The  separately  compiled  procedure  for  PUSH  would  look  something  like 
this: 
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separate(STACK) 
procedure  PUSH(X:REAL)  is 
begin 

r  PTR  :=  PTR  +  1; 

S(PTR)  :=  X; 
end  PUSH; 

Program  Design  Language 

Ada  abstraction  capabilities  may  make  it  a  good  choice  for  a 
program  design  language  (PDL),  even  if  the  ultimate  program  is  coded 
in  another  language.  When  Ada  compilers  are  available  it  will  seldom 
be  necessary  to  code  in  another  language.  There  seems  to  be  growing 
support  for  the  use  of  Ada  as  a  PDL.  The  Air  Force  has  selected  Ada 
as  the  best  "redesign  language"  to  convert  a  large  MIS  to  run  on  new 
hardware  [FILI80].  IBM  Federal  Systems  Division  Intends  to  use  an 
annotated  Ada  for  a  PDL  for  all  new  software  development,  and  to 
eventually  use  Ada  for  the  programing  as  well  [WAR  80].  IBM  likes 
Ada  support  for  design  by  stepwise  refinement  and  for  separating 
specification  from  design.  TRW  believes  Ada  will  help  make  software 
usable  in  more  than  one  project  (the  reusable  code  Idea)  [HART80]. 
They  are  investigating  use  of  Ada  as  a  PDL.  The  Army  Center  for  Tac¬ 
tical  Computer  Systems  has  two  ongoing  software  projects  for  which  Ada 
will  be  the  PDL  and  coding  language  [KERN80]. 

User  Defined  Types 

A  splendid  example  of  the  utility  of  a  user  defined  enumeration 
type  in  handling  control  flow  is  presented  in  [ATKI78J.  The  situation 
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is  a  common  one.  You  wish  to  search  an  array  for  a  certain  item,  but 
you  are  not  certain  whether  or  not  the  item  is  in  the  array.  Let  me 
first  suggest  a  COBOL  solution: 

01  TABLE. 

05  TABLE_A  OCCURS  100  TIMES, 

PICTURE  ... 

•  •  • 

77  END_OF_TABLE  PIC  999  VALUE  100. 

77  T0_END_0F_TABLE  PIC  999. 

77  INDEX  PIC  999. 

•  i  t 

MOVE  1  TO  INDEX. 

PERFORM  SEARCHJ.00P  UNTIL  INDEX  >  END_OF_TABLE 

OR  TABLE_A  (INDEX)  *  ITEM  . 

•  •  • 

SEARCH_L00P. 

ADD  1  TO  INDEX. 

CHECK_STATE. 

IF  INDEX  >  END_OF_TABLE  THEN  ...  ITEM  ABSENT 
ELSE  ...  ITEM  FOUND. 

In  this  search  there  are  three  states  of  Interest: 

-  I  have  not  yet  located  the  Item,  but  I  am  still  searching. 

-  I  found  It. 

-  I  have  searched  the  whole  array  and  the  Item  is  not  In  it. 
This  observation  causes  us  to  think  of  using  an  enumeration  variable 


which  can  take  as  values  the  three  states.  Notice  the  declaration  and 
use  of  the  variable  SEARCHSTATE  In  the  following  Ada  solution,  a 
modification  of  the  Pascal  program  In  IATKI78J: 


ENDOFTABLE  :  constant  :*  100;  —  size  of  array 

type  INDEXRANGE  Is  range  1  ..  ENDOFTABLE; 

type  SEARCHSTATE  is  (SEARCHING,  ITEMFOUND,  ITEMABSENT); 

•  •  • 

TABLE  :  array( INDEXRANGE)  of  ITEM; 

HERE  :  INDEXRANGE; 

OUTCOME  :  SEARCHSTATE; 

•  •  • 

HERE  :=  1; 

OUTCOME  :=  SEARCHING; 
loop 

if  TABLE [HERE]  =  ITEMWANTED  then  OUTCOME  ITEMFOUND; 
elsif  HERE  *  ENDOFTABLE  then  OUTCOME  :=  ITEMABSENT; 
else  HERE  :*  INDEXRANGE *succ( HERE); 
exit  when  OUTCOME  <>  SEARCHING; 
end  loop; 
case  OUTCOME  Is 
when  ITEMFOUND  =>  ...; 
when  ITEMABSENT  =>  ...; 
end  case; 

As  Atkinson  points  out,  the  Ada  program  Is  better  for  several 
reasons  CATKI78J : 

-  the  purpose  of  the  program  Is  more  evident 


-64- 


the  program  can  easily  be  extended  to  handle  other  than  the 


three  simple  cases 

-  after  exit  from  the  loop  it  is  easy  to  determine  “what  state 
you're  in". 

A  similar  approach  can  be  used  in  COBOL,  because  one  can  use  a  string 
variable  to  simulate  an  enumeration  variable,  but  user  defined 
enumeration  types  are  a  more  natural  and  more  efficiently  implemented 
solution. 

Reusable  Code 

Wi nograd  maintains  that  programming  languages  are  not  really 
adequate  to  resolve  the  ongoing  software  crisis  CWIN079].  Evidence  of 
the  crisis  Is  software  which  falls  to  satisfy  user  needs  and  is  too 
costly  to  develop,  maintain,  modify  and  reuse  [FISH78J.  For  though 
programming  languages  are  logically  adequate,  programmers  still  are 
overcome  by  the  complexity  of  large  systems  and  are  perplexed  by  the 
difficulty  of  maintaining  code  written  by  someone  else  £WIN079). 
Winograd  believes  the  basic  problem  is  an  outmoded  idea  of  the 
programmer's  job:  that  one  conceives  of  an  algorithm  for  accomplish¬ 
ing  a  task  and  then  codes  It  in  the  precise  statements  of  a  program¬ 
ming  language.  The  purpose  of  a  high  level  language,  In  this  old 
fashioned  view,  Is  to  provide  tools  for  stating  control  Instructions 
and  expressing  data  structure  at  a  higher  level  than  the  underlying 
machine.  This  purpose  of  a  HOL  Is  still  valid,  but  It  should  no  more 
be  In  the  forefront  of  programmer  concern  than  binary  arithmetic. 
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Today's  large  scale  systems  demand  a  different  approach  to  program¬ 
ming.  Winograd  cites  three  changes  In  the  basic  natur-  of  program¬ 
ming: 

-  The  primary  use  of  computers  has  shifted  from  solution  of  well 
defined,  mathematical  or  data  processing  functions  to  service  in  a 
larger,  complex  system.  The  system  may  be  a  weapons  system  or  a  large 
military  organization  with  a  complicated  structure  and  mission. 

-  The  "building  blocks"  used  to  construct  systems  are  more  broad 
than  programming  language  features.  They  are  subsystems,  "an 
Integrated  collection  of  data  structures,  programs  and  protocols" 
[WIN079J  which  represent  the  solution  to  a  part  of  a  real  world 
problem,  [  Perhaps  Winograd  meant  to  use  the  word  "should"  to  refer 
to  the  practice  of  engineering  new  software  by  linking  together  exist¬ 
ing  modules,  for  though  this  Is  widely  recognized  as  desirable  It  Is 
on  the  fringe  of  the  state  of  the  art] 

-  Programmers  spend  most  of  their  time  not  In  generating  new 
programs,  but  In  Integrating,  modifying  and  documenting  existing  ones. 
Winograd  points  out  that  this  last  trend  results  from  the  first  two. 
The  ability  to  field  more  complex  systems  leads  to  systems  that  keep 
growing  to  suit  the  demands  of  the  environment  CWIN079J. 

This  has  certainly  been  the  case  at  Computer  Systems  Command  In 
recent  years.  More  than  half  of  the  command  resources  are  devoted  to 
system  maintenance  (Including  correction  of  errors  and  modifications). 
Even  "new"  system  developments  are  usually  rewrites  or  extensions  of  a 
previously  existing  system.  In  such  an  environment  there  are  many 
common  sub  functions  among  the  active  systems.  Recognizing  the  great 
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potential  conservation  of  resources,  top  level  managers  have  been  urg¬ 
ing  and  at  times  directing  an  Increase  In  the  use  of  reusable  code. 

This  Is  a  recognition  of  the  recurring  functions  in  new  systems  or 
system  enhancements  which.  If  precautions  are  not  taken,  are  designed 
and  coded  from  scratch  every  time.  A  great  leap  forward  in  programmer 
productivity  Is  theoretically  possible  by  taking  advantage  of  existing 
code  whenever  possible. 

Defining  what  "reusable  code"  is  and  attempting  to  quantify  the 
extent  of  its  use  Is  a  knotty  problem  for  system  developers.  No  clear 
definition  exists,  but  a  recent  survey  uncovered  some  common  practices 
and  attitudes  [SMAR80J.  Reusable  code  Is  variously  interpreted  to 
include  standard  data  divisions,  common  subroutines  (often  for  read, 
write  or  edit  functions),  utilities  provided  by  system  library,  and 
program  skeletons.  Most  system  developers  recognize  the  potential 
cost  savings  and  they  support  Increased  use  of  reusable  code.  Yet  no 
one  believes  that  USACSC  has  sufficiently  exploited  this  technique. 

There  are  limitations  on  taking  advantage  of  the  reusable  code 
concept.  USACSC  develops  systems  to  comply  with  the  functional 
specifications  of  the  customers.  If  specifications  are  not  common, 
then  code  cannot  be  cornnon  either  [SMAR8O3.  Reusable  code,  then, 
depends  on  "reusable  specifications".  There  Is  some  truth  In  this 
assertion,  but  beneath  the  surface  of  customer  functional 
specifications,  down  In  the  successive  levels  of  abstractions  of  an 
Implementation,  there  Is  great  potential  for  employing  reusable  code 
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which  does  not  necessarily  resemble  a  customer  specification.  Perhaps 
this  concept  can  be  labelled,  "reusable  abstractions."  The  Idea  is 
poorly  supported  by  COBOL  but  nicely  done  In  Ada. 

Mechanisms  available  In  USACSC  to  support  reuse  of  code  are  the 
source  library  system  and  the  COBOL  INCLUDE,  COPY  and  CALL  features. 

The  COBOL  COPY  command  allows  a  programmer  to  easily  retrieve  and 
insert  previously  defined  DATA  Division  code,  or  any  other  code,  Into 
his  program.  This  feature  somewhat  supports  the  reusable  code  concept 
but  restricts  one  to  reusing  code  "as  is."  This  Is  much  less  flexible 
than  a  macro  facility  or  the  Ada  package.  Problems  which  reduce  the 
utility  of  the  COPY  scheme  include: 

1.  All  declarations  and  data  structures  are  global.  If  a 
programmer  wants  to  borrow  an  existing  DATA  Division,  all  or  part,  and 
write  a  new  procedure  division  there  Is  no  problem  —  assuming  he 
carefully  uses  the  predefined  data  objects  In  accordance  with  their 
declarations.  But  in  the  general  case  he  may  want  to  take  advantage 
of  several  procedures  from  different  programs.  These  procedures  may 
have  data  declarations  conflicting  with  one  another  or  with  those  in 
the  new  program  being  developed.  So  a  piece  of  code  cannot  con¬ 
veniently  be  "plugged  in"  to  another  program.  Hidden  side  effects  may 
necessitate  a  mammoth  debugging  phase. 

2.  There  Is  no  Interface  specification  for  procedures.  Such  a 
specification,  describing  the  data  types  of  the  parameters  and  all 
other  external  aspects  of  the  procedure.  Is  needed  by  both  the  com¬ 
piler  and  the  programmer.  The  compiler  needs  It  to  link  up  the 
program  segments  and  to  perform  type  checking.  Of  course  COBOL  does 
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little  type  checking  and  the  link  up  Is  simply  In  line  substitution. 
The  programner  must  examine  the  specification  of  candidate  procedures 
In  order  to  intelligently  shop  for  code  that  meets  his  needs  and  to 
determine  what  he  requires  to  interface  with  it.  Comments  in  English 
text  could  aid  in  this  regard  but  they  lack  the  necessary  formality; 
too  much  Is  open  to  Interpretation. 

Though  the  COBOL  COPY  command  is  the  most  prevalent  means  in 
USACSC  of  invoking  reusable  code,  the  CALL  facility  is  potentially 
more  useful,  since  It  does  permit  parameterization  and  separate  com¬ 
pilation.  This  feature  Is  not  selected  very  often  because  COBOL  does 
not  provide  a  convenient  library  or  catalogue,  there  Is  no  provision 
for  formal  description  of  module  specifications,  and  there  is  little 
type  checking  between  separately  compiled  modules.  Ada  offers  an 
Improvement  in  this  regard. 

Though  W1 nograd's  aforementioned  observations  are  sound,  I 
believe  programming  languages  will  play  an  Important  role  in  system 
development  until  the  state  of  the  art  advances  appreciably  "beyond 
programing  languages."  Ada  was  designed  to  be  more  suitable  than 
previous  languages  In  dealing  with  the  software  crisis.  Ada  abstrac¬ 
tion  features  previously  described  should  help  make  reusable  code  a 
reality. 

This  Is  the  belief  of  Ichblah,  principal  Ada  language  designer, 
who  forecasted  that  one  of  Ada's  most  important  contributions  to 
software  engineering  will  be  its  support  for  reusable  software  com¬ 
ponents  CICHB80].  The  most  significant  Ada  features  in  this  regard 
are  packages,  visibility  (naming)  rules,  separate  compilation  and 
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provisions  for  a  library  of  program  units  [ICHB80J.  Ichbiah  hopes 
that  the  package  specification  will  come  to  be  regarded  as  a  contract 
with  the  package  user,  and  the  package  body  will  be  the  fulfillment  of 
the  contract.  Barnes  believes  Ada  abstraction  facilities  will 
encourage  creation  of  reusable  software  libraries  for  all  types  of 
applications,  not  just  numerical  analysis  [BARN80J.  Ichbiah  even 
sees  the  formation  of  a  "package  industry"  of  software  components,  and 
believes  the  time  is  approaching  when  software  modules  will  be 
guaranteed. 

The  guarantee  will  be  like  that  of  a  watchmaker:  valid  as  long 
as  case  remains  intact  and  no  one  has  tampered  with  the  contents.  If 
Ada  packages  (or  the  equivalent)  were  not  available,  on  receiving  a 
complaint  on  a  routine  the  "watchmaker"  would  have  to  check  the  rest 
of  the  program  and  all  programs  which  use  it  to  insure  there  had  been 
no  tampering  with  variables  of  the  routine.  There  is  no  danger  that 
routines  external  to  the  Ada  package  can  cause  any  mischief  with  its 
inner  workings.  But  it  is  quite  possible  for  a  customer  to  look 
inside  the  watchcase  at  the  package  body  and  to  make  assumptions  about 
it  which  may  later  be  invalid  if  the  body  is  revised  for  better 
efficiency.  The  best  course  of  action,  according  to  Ichbiah,  is  not 
to  show  the  implementation  to  the  user.  This  is  feasible  in  Ada  since 
the  package  body  may  be  compiled  separate  from  the  specification. 

Ada  provides  the  same  degree  of  type  checking  across  compilation 
units  as  within  a  unit,  so  there  Is  no  penalty  to  pay  in  this  regard. 
Separately  compiled  units  are  easily  related  logically  by  WITH 
clauses.  The  library  facility  makes  precoded  modules  conveniently 
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available  and  checks  on  obsolescence  during  program  development  as  new 
packages  evolve. 

Portability 

In  this  discussion,  portability  refers  to  the  relative  ease  with 
which  software  can  be  moved  from  one  hardware  environment  to  another. 
There  are  two  approaches  to  portability:  corrective  and  predictive 
[HAGU76J.  Corrective  methods  are  necessary  to  convert  an  existing 
program  originally  written  for  a  particular  computer  with  no 
portability  precautions  taken.  Predictive  methods  plan  ahead.  They 
generally  cost  more  during  development  but  work  best  over  the  life 
cycle. 

A  survey  of  the  U.  S.  Army  Computer  Systems  Command  portability 
problem  [BR0W76]  confirmed  that  the  organization  must  employ  both 
methods.  There  exist  about  4  million  lines  of  COBOL  developed  for  IBM 
machines.  IBM  hardware  has  monopolized  the  army  MIS  market  until 
recent  years.  Competitive  procurements  for  replacement  hardware  are 
causing  a  proliferation  of  target  machines  for  centrally  developed 
software.  Existing  code  must  be  converted  to  run  on  multiple 
architectures,  and  newly  developed  systems  must  be  constructed  to 
minimize  portability  problems. 

Even  though  COBOL  Is  a  HOL,  barriers  to  portability  introduced  by 
varying  machine  architectures  (word  length,  instruction  set,  addres¬ 
sing  structure,  data  representation,  compiler  Implementations,  and 
language  extensions)  can  cause  problems  when  software  Is  moved.  Com¬ 
piler  vendors  provide  COBOL  extensions  which  are  handy  to  programmers 
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but  adversely  impact  software  portability. 

The  USACSC  approach  in  1980  Is  to  achievfe  a  predictive  strategy 
by  adopting  a  standard  subset  of  COBOL,  selected  to  facilitate 
portability.  Existing  code  will  be  converted  oh  a  one  time  basis  to 
the  subset,  and  all  new  work  will  employ  the  subset.  Automated  con¬ 
version  tools  will  be  used  both  to  convert  old  programs  to  the  subset 
and  to  amend  subset  programs  to  run  on  particular  target  machines. 
The  strategy  Is  sound,  but  COBOL  shortcomings  make  the  job  more 
difficult  than  It  has  to  be. 

COBOL  pretends  to  group  all  machine  dependent  characteristics  In 
the  Environment  Division,  a  noble  attempt  to  Identify  changes  required 
to  transport  a  program  to  a  hew  machine.  In  reality  this  Information 
is  rather  arbitrarily  spread  among  the  Environment  Division  and  the 
File  Section  of  the  Data  Division  tJACK76J.  Notice  the  various  places 
you  will  find  the  following  machine  dependent  Information  [JACK76J: 

-  Multiple  records  In  each  tape  block  (FD) 

-  Each  tape  block  Is  prefixed  by  a  length  Indicator  inaccessible 
to  the  user  program  (FD) 

-  A  file  Is  to  be  accessed  only  sequentially  (SELECT) 

-  Designation  of  the  name  of  the  record  key  item  for  a  file 
accessed  by  key  (SELECT). 

Beyond  the  sound  DISPLAY  and  COMPUTATIONAL  formats  for  elementary 
data  1tem$,  COBOL  allows  compiler  designers  to  establish  special 
formats  for  efficient  Implementation  on  a  particular  machine.  For 
example,  many  IBM  compilers  Implement  COMP,  COMP-1,  -2,-3  and  -4. 
This  allows  a  programmer  to  take  advantage  of  his  knowledge  of  the 
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actual  machine  representation  of  data.  For  example,  the  following 
trick  may  be  used  to  save  space  in  a  file  record  by  getting  an 
unsigned  packed  decimal  item  £JACK76J: 

03  FIELD-A  PICTURE  S9(5)  COMPUTATIONAL^. 

03  FILLER  REDEFINES  FIELD-A. 

05  FIELD-B  PICTURE  XX. 

05  FILLER  PICTURE  X. 

FIELD-B  will  contain  the  four  most  significant  digits  of  FIELD-A.  Now 
the  programmer  can  add  1  to  FIELD-B  by  adding  10  to  FIELD-A. 

Machine  dependencies  are  much  more  evident  in  Ada  and  are  acces¬ 
sible  in  the  source  language.  Every  implementation  of  Ada  must 
include  a  package  SYSTEM  which  makes  available  to  the  source  program¬ 
mer  certain  attributes  of  the  underlying  hardware  [ADA  80]: 
package  SYSTEM  is 

type  SYSTEM_NAME  is  —  implementation  defined  enumeration  type 
NAME  :  constant  SYSTEM_NAME  :=  —  the  name  of  the  system 
STORAGEJJNIT:  constant  :=  —the  number  of  bits  per  storage  unit 
MEMORY_SIZE  :  constant  :=  —number  of  storage  units  in  memory 
MIN_INT  :  constant  :=  --smallest  integer  supported 
MAX_INT  :  constant  :=  —largest  integer  supported 
•  •  • 

end  SYSTEM; 

A  generous  number  of  other  predefined  attributes  are  available  ,  such 
as: 

-  SIZE  :  the  number  of  bits  used  to  Implement  a  type 
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-  MACHINE_ROUNDS  :  value  Is  true  If  rounding  occurs  for  arith¬ 
metic  on  a  particular  type 

-  MANTISSA  :  number  of  machine  radix  places  In  the  mantissa 

-  OVERFLOWS  :  true  if  the  exception  NUMERIC_ERROR  is  raised  for 
computations  which  exceed  the  range  of  real  arithmetic. 

There  are  other  features  which  help  Identify  and  Isolate  machine 
dependencies.  Explicit  declaration  of  ranges  of  numeric  variables  is 
helpful,  and  machine  dependent  portions  of  a  program  can  be  Isolated 
from  the  rest  of  the  program  In  a  separate  package. 

A  1980  software  conversion  effort  of  the  U.  S.  Air  Force  Man¬ 
power  Personnel  Center  (AFMPC)  is  a  relevant  case  study  in  Ada 
portability.  The  AFMPC  problem  Is  to  convert  a  large  ALGOL  based 
information  retrieval  system,  ATLAS,  to  run  on  new  hardware.  They 
have  decided  to  convert  existing  software  to  a  more  portable  form  even 
before  the  new  hardware  is  selected,  because  the  time  between  hardware 
selection  and  the  due  date  for  the  software  conversion  will  be  too 
short  to  achieve  an  automatic  conversion.  Even  though  no  Ada  compiler 
exists  in  1980,  AFMPC  decided  that  Ada  had  so  many  portability 

advantages  over  COBOL  and  FORTRAN  that  they  should  translate  ATLAS 
Into  Ada  as  a  preliminary  step  In  the  conversion  to  new  hardware. 
This  is  their  plan,  even  though  they  had  to  construct  an  Ada 

translator  for  use  In  the  recoding  of  ATLAS.  Further  details  of  this 
effort  can  be  found  in  fFILI80J . 

Exception  Handling 

Ada  was  designed  for  real  time  systems  which  must  be  able  to 
recover  from  errors  and  continue  operation.  Therefore,  Ada  provides 


an  exception  handling  capability.  What  constitutes  an  exception  is 
open  to  interpretation.  There  are  two  approaches  fADA  79].  The  first 
is  a  general  view  which  considers  exception  handling  an  ordinary 
programming  solution  for  dealing  with  any  unusual  events  --  not  just 
errors.  Ada  Implements  the  second,  more  narrow  approach:  exceptions 
are  synonymous  with  errors  and  they  mandate  a  termination  of  the 
program  unit  in  which  they  occur.  Exception  conditions  automatically 
cause  a  transfer  of  control  to  the  user  defined  exception  handler  for 
that  condition.  The  handler  achieves  whatever  recovery  actions  the 
programmer  has  provided.  Actions  may  Include  restarting  the  procedure 
in  which  the  exception  occurred,  but  this  would  be  a  new  Invocation. 

Exception  handling  in  COBOL  is  limited  to  an  ability  for  certain 
statements  to  transfer  control  to  a  user  defined  routine  upon 
occurrence  of  one  of  a  fixed,  restricted  set  of  errors.  Usually  there 
is  just  one  error  condition  which  may  be  handled  for  each  type 
statement.  For  example: 

READ  INPUT_FILE  AT  END  GO  TO  EDIT_ROUTINE. 

WRITE  MASTER_REC  INVALID  KEY  PERFORM  WRITE_ERROR. 

COMPUTE  PAY  =  HOURS  *  RATE  ON  SIZE  ERROR  PERFORM 

0VERFL0W_R0UTINE. 

Ada  exception  conditions  are  not  limited  to  a  predefined  set. 
The  programmer  can  define  as  many  exceptions  as  are  appropriate,  and 
choosing  descriptive  exception  names  contributes  greatly  to  program 
readability  and  facilitates  debugging.  Consider  the  following  outline 
of  a  procedure  used  to  determine  the  stockage  level  of  parts  having  a 
given  part  number: 
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procedure  GET_PART_STOCKAGE ( PART_N0 : PART_NO_TYPE , 

NUMBER  :  out  INTEGER); 


► 


begin 
•  •  • 

GET_NEXT_PART_RECORD ( REC  :  PART_RECORD) ; 

—above  procedure  raises  exception  END_OF_FILE_ERROR  when  end 

—  of  file  is  reached  before  a  matching  part  number  is  found. 

•  •  • 

exception 

when  END_0F_F ILE_ERR0R  =>  raise  I NVAL I D_P ART_N0 ; 

—the  ENDjOF  FILE  ERROR  exception  is  handled  here  by 
—raising  a  cfescrTptive  exception  which  will  be  handled 
— by  the  routines  calling  GET_PART_STOCKAGE . 

A  programmer  can  also  handle  the  five  predefined  Ada  exceptions. 
These  include  the  too  familiar  NUMERIC_ERROR  (otherwise  known  as 
"overflow",  "divide  check",  etc.  in  other  languages)  and 

CON STRAI NT_ERR0R ,  which  has  the  same  purpose  but  pertains  to  program¬ 
mer  defined  range  and  index  constraints  rather  than  underlying  hard¬ 
ware  limitations. 

Is  this  capability  useful  in  MIS  applications?  I  think  so. 
Permit  a  digression  and  consider  one  sample  situation:  batch  oriented 
MIS  in  an  Army  division  in  Europe.  Like  many  army  sites,  the  division 
computer  center  operates  at  or  near  saturation,  and  abnormal  termina¬ 
tion  of  any  run  may  cause  serious  problems  to  customers.  Most 
application  software  is  configured  such  that  there  are  restart  points, 
but  several  hours  processing  time  can  still  be  lost  by  a  failure 
between  restart  points.  Lost  time  usually  translates  directly  to 
delay  in  producing  output  for  the  customer. 
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The  automated  repair  part  resupply  system  is  one  of  the  most 
critical  to  the  maintenance  of  combat  readiness.  Requisitions  from 
customer  organizations  are  collected,  consolidated,  and  keypunched 
daily.  Typically  the  daily  batch  of  requisitions  is  submitted  to  the 
computer  center  at  11:00  P.M.  for  a  reserved  block  of  processing  time 
that  begins  soon  after  the  input  arrives.  If  the  computer  and 
software  run  smoothly  through  the  night,  the  output  is  ready  for 
customer  pick  up  at  7:00  A.M.  The  most  critical  part  of  the  output  is 
a  punched  and  interpreted  card  deck  of  repair  parts  release  orders 
used  to  direct  parts  to  customers.  If  the  output  is  delayed,  then 
repair  parts  warehouse  workers  encounter  a  work  stoppage,  and  while 
tney  are  wasting  time  so  are  mechanics  in  customer  units  who  are  wait¬ 
ing  for  parts  to  repair  equipment.  This  situation  illustrates  the 
high  cost  of  a  program  "abort"  in  a  MIS  environment  —  real  time 
systems  do  not  have  a  monopoly  on  this  problem. 

The  most  costly  (lengthy  to  fix)  aborts  result  from  exceptions 
which  are  not  handled  by  the  application  software;  rather,  they  are 
trapped  by  the  operating  system  or  the  hardware.  Such  terminations 
usually  provide  few  useful  clues  about  what  went  wrong.  Often  a  cryp¬ 
tic  code  is  the  only  signal,  and  when  one  looks  up  the  description  of 
the  code  In  a  system  manual  one  finds  it  also  has  no  clear  relevance 
to  the  original  problem  In  the  application  program. 

While  local  analysts  try  to  troubleshoot,  with  few  clues,  the 
computer  center  manager  receives  calls  from  anxious  cusuvxners  who 
demand  to  know  when  they  will  get  their  output.  Perhaps  enough  detail 
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of  the  scenario  has  been  presented  to  establish  this  point:  applica¬ 
tion  programs  should  handle  their  own  "dirty  laundry."  As  many  excep¬ 
tions  as  possible  should  be  handled  by  the  program  so  that  the  program 
can  continue  operation.  If  it  must  terminate,  the  program  should  at 
least  provide  meaningful  diagnostic  messages. 

I  believe  Ada  exception  handling  provides  a  convenient,  natural 
system  that  encourages  prograrmiers  to  fulfill  their  responsibilities 
toward  exceptions. 

Syntax  and  Structure 

Richard  Wexelbat  [WEXL76J,  while  teaching  a  course  on  "The  Design 
of  computer  Languages  and  Systems  for  Human  Use,"  Included  a  whimsical 
question  on  his  final  exams.  Students  were  asked  to  consider  their 
e>-erience  and  the  insight  gained  from  the  course  to  cite  ways  that 
malevolent  programming  language  designers  could  intentionally  make 
programing  difficult  and  erroneous.  Resulting  is  a  catalogue  of 
things  which  should  be  avoided  in  programming  language  design  but  are 
evident  in  COBOL: 

-  "Make  unnatural  restrictions  on  the  use  of  delimiters"  e.g. 
blanks  must  be  used  around  arithmetic  operators  in  COBOL.  X+Y  does 
not  work;  X+Y  must  be  used. 

-  "Do  not  provide  function  subprograms  "Like  most  languages,  Ada 
permits  a  program  segment  to  return  a  value  in  the  fashion  of  a 
mathematical  function  such  as: 

IF  AVG ( P00R_STUDENT_6RADES )  >  {5  +  AVG(RICH_STUDENT_GRADES) ) 

THEN  ... 
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In  COBOL,  in  such  a  case  one  must  use  two  arguments,  one  to  pass  a 
table  of  values  and  one  to  receive  the  resulting  computation: 

CALL  "AVERAGE"  USING  POOR_STUDENT_GRADES ,  P00R_AVG. 

CALL  "AVERAGE"  USING  R I CH_STUDENT_GRADES ,  RICH_AVG. 

ADD  5  TO  RICH_AVG. 

IF  POORJWG  IS  GREATER  THAN  RICHAVG  ... 

-  "Place  excessive  restrictions  on  arrays  and  subscripting." 
Programmers  are  aggravated  by  arbitrary  restrictions  on  array  bounds. 
COBOL  restricts  the  lower  bound  to  1.  In  Ada,  any  value  may  be 
chosen. 

Gannon  calls  the  COBOL  IF  statement  error  prone,  and  the  allega¬ 
tion  Is  serious  since  this  is  the  only  selection  statement  available 
JGANN78] .  Gannon  overlooks  the  GO  TO  OEPENOING  ON,  a  construct  not 
recommended  here  but  one  which  Indeed  provides  a  multiway  branch  which 
can  be  used  for  selection.  Suppose,  for  example,  that  one  wanted  to 
add  the  statement  S3  to  the  ELSE  clause  of  the  following  IF  statement, 
but  the  programmer  forgot  to  move  the  period  from  after  S2  to  after 
S3: 


IF  ... 

THEN 

SI 

ELSE 

S2. 

S3 

Now  S3  will  be  executed  unconditionally,  but  this  fact  Is  not  obvious 
to  the  programmer.  We  have  here  an  excellent  candidate  for  a 
difficult  logic  error.  Even  when  the  position  of  the  period  Is  not 
mistaken,  its  meaning  can  be  confusing.  The  period  terminates  an 
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entire  statement;  it  cannot  be  used  to  delimit  IF's  in  a  nested  IF 
statement. 

Ada  provides  a  safer  construct  with  an  "end  if"  to  more 
explicitly  terminate  an  IF  statement.  Example: 

if  ... 
then 

51 
else 

52 

end  if; 

53 

Notice  how  much  easier  it  Is  to  see  that  S3  Is  not  part  of  the  else 
clause. 

The  structured  programming  approach  encourages  using  nested  IF 
statements  to  avoid  GO  TO’s,  but  psychologists  report  that  the 
difficulty  to  understand  a  sentence  Increases  with  the  level  of  "self 
embedding"  [MILL64J .  Sime,  Green  and  Guest  [SIME73J  verified  this 
problem  using  subjects  employing  IF  statements  In  simple  programs. 
One  commonly  occurring  situation  is  the  need  to  select  from  a  number 
of  alternatives  based  on  the  value  of  a  variable.  A  nested  IF  may  be 
used  for  this  purpose  In  COBOL.  Example: 

IF  TODAY  *  'MON' 

THEN  PERFORM  UPDATEJNITIALJALANCE 
ELSE  IF  TODAY  =  'FRI ' 

THEN  PERFORM  UPDATE_CLOS ING_BALANCE 
ELSE  IF  TODAY  *  'TUE'  OR  TODAY  «  'WED'  OR  TODAY  -  'THU' 

THEN  PERFORM  PRI NT_REP0RT_T0DAY . 

The  above  example  uses  "a  nested  If  that  really  isn't  nested".  The 
statement  is  rather  easy  to  understand,  and  its  complexity  does  not 
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grow  with  the  number  of  alternatives.  Nevertheless,  Weinberg,  Geller 
and  Plum  CWEIN75]  advocate  use  of  a  more  linear  construct.  The  Ada 
CASE  statement  seems  to  provide  a  more  desirable  structure,  for  even 
though  nesting  is  allowed,  it  will  seldom  be  necessary  because  the 
CASE  provides  a  choice  between  multiple  alternatives.  Example: 
case  TODAY  is 

when  MON  =>  UPDATE_INITIAl_BALANCE; 
when  FRI  =>  UPDATE_CLOS ING_BALANCE ; 
when  TUE..THU  =>  PR INT_REPORT( TODAY); 
when  SAT.. SUN  =>  null; 
end  case; 

Ada  Programming  Support  Environment 

DoD  plans  to  develop  a  contnon  support  environment  for  Ada.  This 
is  a  recognition  that  the  environment  and  support  tools  for  most 
existing  HOL's  have  been  vendor  defined  and  often  leave  much  to  be 
desired.  The  Ada  Programming  Support  Environment  (APSE)  will  be  an 
integrated  collection  of  tools  "to  support  development  and  maintenance 
of  Ada  application  software  throughout  Its  life  cycle"  [ST0N80]. 
Minimum  features  of  the  APSE  Include  a  text  editor,  pretty  printer, 
Ada  translator,  linker,  loader,  set-use  static  analyzer,  control  flow 
static  analyzer,  dynamic  analyze.,  and  others.  The  APSE  will  be 
extendable  to  support  life  cycle  management  activities:  requirements 
specification,  overall  system  design,  programming  design,  program 
verification  and  project  management. 

Serious  efforts  already  underway  give  credibility  to  the  APSE 
vision.  Fairley  has  formulated  design  considerations  for  interactive 
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debugging  and  testing  support  environments  JFAIR80J.  There  are 
several  proposed  methods  for  Ada  program  verification,  all  worthy  can¬ 
didates  for  Inclusion  In  APSE.  For  example,  a  recently  developed 
formal  annotation  language,  ANNA,  could  be  the  basis  for  a  verifica¬ 
tion  tool  [KRIE80J. 

To  be  fair  to  COBOL  I  must  acknowledge  that  a  fancy  support 
environment  could  be  designed  for  COBOL  as  well.  But  It  appears  that 
Ada  Is  destined,  with  DoD  support,  to  have  a  rather  powerful, 
standardized  support  environment,  and  It  may  be  too  late  to  try  to 
establish  a  standard  environment  for  COBOL. 

Things  Ada  Does  Not  Do  Well: 

Numeric  Editing 

COBOL  programmers  often  use  a  record  to  format  and  label  numeric 

data: 

01  T  IME_CARD_DETAI  L_L  I NE . 

03  EMPLOYEE_NAME  PICTURE  X(20). 

03  EMPLOYEE_TOTAL_EARNINGS  PICTURE  $$$$.99. 

If  the  value  '12.34'  were  stored  In  EMPLOYEE_TOTAL_EARNINGS  the  result 
would  be  represented  as  'b$12.34',  where  the  quotes  are  added  here 
only  as  delimiters  and  the  * b '  represents  a  blank.  COBOL  has  an 
extensive  set  of  built  In  features  for  editing  numeric  data  via  record 
'templates',  and  It  Is  not  yet  clear  how  Ada  can  provide  a  reasonable 
facsimile.  If  there  Is  no  natural  solution  that  does  not  mean  the 
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editing  cannot  be  done;  It  just  will  not  be  as  easy  as  It  Is  In  COBOL. 
Many  language  design  experts  object  to  automatic  type  conversion,  but 
the  utility  of  COBOL  numeric  editing  must  not  be  overlooked.  Format¬ 
ting  of  MIS  output  Is  very  important  to  users  and  is  susceptible  to 
frequent  changes.  Lack  of  a  convenient  Ada  solution  constitutes  a 
significant  shortcoming. 

For  the  time  being,  an  Ada  solution  is  presented  for  a  simple 
case:  fixed  point  numbers  without  special  editing. 

COBOL 

01  T IME_CARD_DETA I  L_L I N  E . 

03  EMPLOYEE_NAME_P ICTURE  X(20). 

03  EMPLOYEE  TOTAL  EARNINGS  PICTURE  999.99. 


Ada 

type  T I  ME_CARD_DET  A I  L_L  I N  E_T  Y  P  E  Is 
record 

EMPLOYEE_NAME  :  STRING(1  ..  20); 

EMPLOYEE_TOTAL_EARNINGS  :  delta  .01  range  0.0  ..  999.99; 
end  record; 

T I  ME JC  ARD_DE  TA I  L_L  I NE  :  TIME_CARD_DETAIL_L  INE_TYPE; 

Notice  the  ability  to  constrain  the  range  of  numeric  types.  This 
provides  the  benefit  of  automatic  run  time  checking  for  violation  of 
the  range  —  a  potential  bug  prevention  medicine. 
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Record  Input/Output 


COBOL  records  are  associated  with  (bound  to)  "ordinary"  files  for 
Input  and  output  and  with  "sort"  files. 

The  following  COBOL  example  includes  an  "FD"  (File  Description) 
which  precedes  the  record(s)  declared  to  be  associated  with  the  file: 


FD  LOAN_MASTER_F I LE 

RECORD  CONTAINS  33  CHARACTERS 
LABEL  RECORDS  ARE  STANDARD 
DATA  RECORD  IS  L0AN_REC0RD . 

01  LOAN_RECORD. 

05  ACCOUNT_NUMBER  PICTURE  9(6). 

05  NAME  PICTURE  X(20). 

05  L0AN_AM0UNT  PICTURE  9(5)V99. 

The  Ada  package  provides  a  natural  way  to  associate  one  or  more 
records  with  a  file.  One  may  declare  a  record  type,  record  objects  of 
that  type,  plus  READ/WRITE  operations  on  records  of  that  type,  all  in 
the  same  package. 
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package  LOAN_MASTE R_F I LE_P ACKAGE  Is 
type  LOAN_RECORD_TYPE  Is 
record 

ACCOUNT_NUMBER  :  range  0  .,  999999; 

NAME  :  STR I NG( 1  ..  20); 

L0AN_AM0UNT  :  delta  .01  range  0.0  ..  99999.99; 
end  record; 

L0AN_REC0RD  :  LOAN_RECORD_TYPE ; 
procedure  WRITE  (RECORD  :  LOAN_RECORD_TYPE) ; 
procedure  READ  (RECORD  :  LOAN_RECORD_TYPE); 
end  LOAN_MASTER_FILE_PACKAGE ; 

The  READ  and  WRITE  procedures  contain  necessary  instructions  to  read 
and  write  records  of  the  specified  type  to  the  associated  file.  The 
programmer  may  then  use  a  simple  Instruction  like 
WRITE (L0AN_REC0RD); 

to  write  a  record  to  its  associated  file.  Notice  that  this  scheme 
overloads  the  WRITE  procedure,  but  there  need  be  no  confusion  to  the 
programmer  or  compiler.  The  compiler  will  properly  distinguish  which 
WRITE  procedure  Is  Intended  by  examining  the  number  and  type  of 
parameters.  Since  I  assume  the  programmer  will  make  a  separate  type 
declaration  for  the  records  associated  with  each  file,  the  overloading 
should  work  as  desired  and  allow  the  programmer  to  express  his  I/O 
Instructions  simply  and  logically.  The  programmer  may  define  several 
records,  each  of  which  represents  a  format  (data  template)  for  data  In 
the  file.  This  Is  convenient  when  various  views  of  the  data  In  the 
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record  are  necessary.  The  programmer  has  the  illusion  that  all  the 
various  records  associated  with  an  input  file  are  appropriately  filled 
for  each  READ  of  the  file.  For  output  the  programmer  need  fill  only 
one  of  the  defined  output  file  records  with  data.  The  chosen  record 
is  then  written  to  the  associated  file.  The  scheme  is  summarized  by 
the  rule  "read  a  file  —  write  a  record". 

Called  "aliasing",  this  ability  to  define  multiple  record  tem¬ 
plates  for  the  same  data  object  is  a  source  of  confusion  to  the  reader 
of  a  program.  Many  language  design  experts  frown  on  allowing  more 
than  one  name  for  the  same  data  object.  Several  other  COBOL  options 
rl so  result  in  aliasing:  REDEFINES,  RENAMES  and  SAME  AREA.  RENAMES 
is  to  be  deleted  in  the  next  edition  (an  Improvement)  [COBOL  80J. 

Consider  the  convenience  of  COBOL  automatic  type  conversion  which 
makes  It  easy  to  print  records  of  any  format.  Usually  programmers 
associate  a  "string  type"  record  with  the  output  file  such  as: 

01  PRINT_REC. 

03  FILLER  PIC  X(l). 

03  PRINTLINE  PIC  X(132). 

The  first  character  is  reserved  for  printer  control  and  Is  often 
initialized  to  SPACE  for  single  spacing.  A  line  of  output  Is  first 
transferred  to  PRINTLINE  with  a  statement  like  MOVE  SUMMARY_LINE  TO 
PRINTLINE,  and  then  the  line  is  printed  by  the  statement  WRITE 
PRINT_REC.  Notice  that  there  Is  no  type  checking  Involved;  a  record 
of  any  format  may  be  moved  to  PRINTJLINE  and  then  printed. 

The  Ada  progranmer  must  be  aware  of  type  compatibility.  An  Ada 
file  Is  constrained  to  consist  of  elements  all  of  the  same  type.  The 
COBOL  ability  to  intermix  varying  record  types  in  the  same  file  is 
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conceptually  a  free  or  undiscriminated  union  of  types.  In  order  to 
conveniently  associate  various  record  formats  with  a  particular  Ada 
file,  the  progranmer  will  probably  choose  the  variant  record 
construct.  Paying  the  penalty  of  declaring  a  tag  field  (which 
designates  the  variant)  one  may  achieve  much  the  same  capability  as 
COBOL:  varied  record  formats  under  the  same  umbrella  (record  name). 
The  major  difference  is  that  the  tag  must  be  properly  set  when  a 
record  is  created  and  must  be  checked  each  time  a  record  is  read.  The 
compiler  can  save  space  in  allocating  storage.  Normally  space  is 
necessary  only  for  the  largest  variant;  all  variants  can  be  overlaid 
in  the  same  area.  The  tag  field  reveals  which  variant  is  applicable. 
It  is  a  matter  of  taste  whether  this  explicit  control  is  better  than 
automatic  type  conversion,  but  the  modern  trend  is  toward  explicit 
control . 

Ada  can  mimic  the  "read  a  file"  scheme  of  COBOL,  since  after  each 
record  is  read  the  tag  can  be  examined  to  determine  which  variant 
exists.  Then  the  appropriate  view  of  the  record  is  known  and 
available.  Example: 
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type  LINEJMT  is  (HEADING, DETAIL, SUMMARY) ; 
type  MASTER_REC_TYPE ( TAG : L I NE_FMT )  Is 
record 
case  TAG  is 
when  HEADING  => 

TITLE:  constant  STRING  :=  "MONTHLY  STATEMENT"; 
DATE:  DATE_TYPE; 
when  DETAIL  => 

CHECK_DATE:  DATE_TYPE; 

CHECK_AMT :  AMT_TYPE; 
when  SUMMARY  => 

BAL_LABEL:  constant  STRING  :=  "BALANCE"; 
BALANCE  :  AMTTYPE; 
end  case; 
end  record; 


READ(MASTER_FILE) ;  —  file  of  MASTER_REC_TYPE 
case  TAG  is 
when  HEADING  =>  ...; 

when  DETAIL  =>  ...; 
when  SUMMARY  =>  ...; 
end  case; 

The  simulation  of  the  COBOL  scheme  may  be  carried  further  by  defining 
a  READ  procedure  that  reads  a  variant  record,  checks  the  tag,  and 
stores  the  contents  In  the  appropriate  record  —  one  of  a  collection 
of  records,  one  for  each  variant.  This  approach  Is  wasteful  of 
storage. 


Variant  records  can  be  difficult  because  Ada  strong  typing  Is 
rather  unforgiving.  An  attempt  to  intermix  records  on  an  Ada  print 
file  causes  a  tag  problem  reminiscent  of  the  famous  line  from 
Shakespeare,  "Out  damned  spot"  (substitute  "tag"  for  "spot").  Ada 
strong  typing  prevents  disassociating  components  of  the  variant  record 
from  the  tag.  For  example,  suppose  that  we  define  a  print  file  of  the 
same  type  records  as  MASTER_FILE: 

package  PRINT_0UT 

is  new  INPUT_OUTPUT(ELEMENT_TYPE  =>  MASTER_REC_TYPE) ; 

There  seems  to  be  no  way  to  print  the  records  of  this  file  without 
also  printing  the  value  of  TAG!  Since  the  tag  usually  serves  only  to 
discriminate  between  variants,  it  makes  no  sense  to  print  it  along 
with  the  rest  of  the  record. 

One  possible  solution  is  to  employ  unchecked  type  conversion  to 
get  a  handle  on  the  record  minus  Its  tag. 

COBOL  provides  a  report  writer  tool  which  simplifies  formatting 
printed  output.  Ada  provides  only  a  basic  set  of  I/O  primitives,  but 
a  similar  facility  could  be  established  as  a  user  defined  Ada  package. 
LeBlanc  has  developed  a  text  formatter  package  with  many  of  the  com¬ 
monly  desired  features  fLEB80a],  The  main  issue  is  run  time 
efficiency.  It  remains  to  be  seen  whether  an  Ada  package  can  compete 
with  COBOL's  built-in  report  writer  in  run  time  efficiency. 
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Conclusions 


The  Ada  and  MCF  programs  constitute  a  revolution  in  Department  of 
Defense  embedded  computer  technology.  As  Ada  oriented  embedded  com¬ 
puters  begin  to  dominate  the  battlefield,  military  MIS  developers 
will  find  It  increasingly  attractive  to  take  advantage  of  the 
technology  advances  associated  with  "strength  in  numbers".  Adoption 
of  Ada  for  MIS  would  reap  significant  advantages  in  the  "higher  level" 
aspects  of  software  development:  management  of  software  develop¬ 
ment,  program  design,  overall  readability  and  maintainability. 
The  ability  to  describe  module  specifications  apart  from  their  imple¬ 
mentation  encourages  top  down  design.  Since  the  package  specifica¬ 
tion  can  serve  as  a  contract  for  the  programmer  of  a  module,  a  soft¬ 
ware  development  manager  can  allocate  programming  work  via  the 
specifications.  Interfacing  the  work  of  a  team  of  programmers 
is  relatively  straightforward.  Ada  strong  typing,  separate  com¬ 
pilation  and  information  hiding  help  preclude  Inadvertent  damage 
of  the  inner  workings  of  one  package  by  another.  There  should 
be  few  surprises  when  modules  are  linked  together  for  system  testing. 
Opportunities  for  reusing  code  are  Increased  by  the  Ada  facilities  for 
data  abstraction. 

Since  most  software  development  costs  are  now  attributed  to  the 
maintenance  phase,  the  use  of  Ada  may  be  a  net  Improvement  over 
COBOL.  Ada  programs  will  tend  to  be  much  easier  to  understand  and 
modify.  This  should  outweigh  any  additional  cost  that  might  be 
Incurred  in  initial  coding,  resulting  in  lower  total  life  cycle  cost. 
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Yes,  Ada  has  many  advantages,  but  serious  problems  must  be  over¬ 
come  before  Ada  is  a  sound  candidate  for  MIS  applications.  The  Primary 
challenge  confronting  prospective  users  of  Ada  is  the  difficulty  of 
retraining  COBOL  programmers.  Ada  seems  more  difficult  to  learn.  At 
the  statement  level,  Ada  Is  probably  less  readable  than  COBOL, 
Many  of  Its  concepts  are  foreign  to  even  the  most  accomplished  COBOL 
programmers.  At  the  detailed  coding  level,  after  program  specifica¬ 
tions  are  completed,  COBOL  appears  to  facilitate  a  faster,  more  natural 
solution  to  problems  frequently  encountered  by  programmers  of  MIS. 
Convenient  COBOL  provided  features  such  as  numeric  editing  and  record 
Input/output  will  have  to  be  self  constructed  Ada  tools,  at  least 
until  a  substantial  library  of  reusable  "MIS  tool  kit"  packages  Is 
developed. 

Ada  and  MCF  are  not  a  threat  to  the  COBOL  community.  Rather  they 
present  an  opportunity  for  long  term  Improvement  In  MIS  development. 
There  Is  no  need  for  haste  In  deciding  what  to  do.  After  all,  as  of 
1980  Ada  Is  just  a  design,  but  C080L  Is  a  reality  with  almost  two  dec¬ 
ades  of  experience.  The  best  tack  Is  a  "wait  and  see"  approach,  with 
emphasis  on  the  "see". 
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